text:
Logging.

Good logging should be a high priority item. Python's logging is great...
Some options:

Base logging
Memento.jl
MicroLogging.jl

Hi, I'd like to help out with this! What would you like logged?

Hey @arcavaliere that would be awesome if you have the time! It's not a glamorous issue but super important for developing good software.
How familiar are you with Julia?
I think the first step is to figure out how to use the logging macros, e.g. @info and @debug, to print the current time (and possibly even filename and line number) to provide more useful logging messages.
So instead of
julia> @info "Test line"
[ Info: Test line

which isn't super useful hopefully we can have logging messages like
julia> @info "Test line"
[09/10/2019 16:12:33] some_file.jl:55: Test line

which would be more useful.
If that's possible, I think we can start logging a lot more stuff knowing that the messages will have useful timestamps and line numbers.

@ali-ramadhan I'm just getting started with Julia (coming from a Python background). I'll start looking into those macros!

@arcavaliere just to clarify what I think this issue is all about: during a simulation we often would like to print messages that inform us of the simulation's progress. One example of this comes from a @printf statement inside a time-stepping loop in our wind mixing and convection example:
https://github.com/climate-machine/Oceananigans.jl/blob/ca814dbe608487857c06a51a7383350dcf1e46f4/examples/ocean_wind_mixing_and_convection.jl#L199
This printing produces a stream of messages during the simulation:
julia> include("ocean_wind_mixing_and_convection.jl")
i: 0010, t: 11.000 s, Δt: 1.100 s, wmax = 7.8e-04 ms⁻¹, wall time: 594.383 ms
i: 0020, t: 23.100 s, Δt: 1.210 s, wmax = 1.5e-03 ms⁻¹, wall time: 581.628 ms
i: 0030, t: 36.410 s, Δt: 1.331 s, wmax = 2.3e-03 ms⁻¹, wall time: 567.346 ms
i: 0040, t: 51.051 s, Δt: 1.464 s, wmax = 3.2e-03 ms⁻¹, wall time: 562.455 ms
i: 0050, t: 1.119 min, Δt: 1.611 s, wmax = 4.2e-03 ms⁻¹, wall time: 576.511 ms
i: 0060, t: 1.415 min, Δt: 1.772 s, wmax = 5.2e-03 ms⁻¹, wall time: 571.096 ms

In this case, the information we decide to print is:

iteration number i
the simulation time t
the time-step (because we are using adaptive time-stepping)
the maximum vertical velocity
the elapsed wall time for time stepping only (not including plotting) between print messages

I think this issue is about a better way to achieve the printing of simulation progress. Two ideas are:

Somehow use a logging package (though I'm not 100% what this would look like --- perhaps this means adding lines to our time-stepping loop?
Create some types that allow the user to more easily manage the printing of progress messages, expanding on the pattern used in our example.

I've thought a bit about 2: I think a generic progress messenger would be both configurable but also include some comforting defaults. A simple way to start could be something like
struct ProgressPrinter{DT, M, D}
    Δt :: DT
    model :: M
    diagnostics :: D
end

with some kind of print function, something like
pretty_Δt(Δt::Number) = prettytime(Δt)
pretty_Δt(Δt::TimeStepWizard) = prettytime(wizard.Δt)

function Base.print(progress::ProgressMessenger)
    @printf("i: %04d, t: %s, Δt: %s,
            progress.model.clock.iteration, prettytime(progress.model.clock.time), pretty_Δt(progress.Δt))
    return nothing
end

One could then expand on this design by setting up the diagnostics field to accept a list of callable objects or functions. Or even better, a list of objects that look something like
struct PrintableDiagnostic{D}
    diagnostic :: D
    format :: String
    name :: String
    units :: String
end

function pretty_diagnostic(pd::PrintableDiagnostic, model)
    return @sprintf("%s: $(pd.format) %s", pd.name, pd.diagnostic(model), pd.units)
end

with this design, the user can pass a list of PrintableDiagnostics to ProgressPrinter, which are then evaluated and the results turned into a string via the function pretty_diagnostic.
As for option 1 of using a logging package, perhaps it could be nice to use some logging functionality that's configurable with global variables (?) rather than manually creating a ProgressPrinter that does "brute force" printing as I have described above. However I think that it would require some customization of existing logging packages, since the typical info or debug settings are not sufficient for the purposes of logging simulation output (right?) Instead, we would need more options, and it'd be nice to obtain the ability to also print the output of diagnostics / monitoring functions, as we do in the example script. And I think doing it this way might involve adding some lines to our time stepping loop.
Perhaps @ali-ramadhan has more to say.
Another thing we have talked about is somehow having the ability to live-update messages in the terminal (rather than printing a stream of message). This would be nice because it could dramatically reduce the text-noise that a stream of messages invokes, allowing the user to much more easily read and interpret the output of a simulation progress (in addition to creating the possibility for nice pseudo-animations via UnicodePlots.jl). I'm not 100% sure how to do this; one places to start could be https://github.com/ronisbr/TextUserInterfaces.jl.
Any work on any of these ideas could be useful! I'd be happy to Skype to talk more and clarify any questions.

These are definitely cool ideas for progress statements!
I see logging as being much more general though. It should also be used when printing progress statements, but I think it's especially useful to have @debug messages in certain places to help with debugging.
And maybe @info messages so the user knows what the model is doing. It could get noisy if we get carried away with them but a user staring at a blank screen for 3 minutes might not know that the GPU stuff is just compiling in the background. More responsive software feels more user-friendly.

That sounds like it could be nice; can you maybe give some examples? These messages used in constructors perhaps?
So there are two issues: simulation progress statements, and logging for model construction / instantiation?

I started working on a ModelLogger that will handle printing @info calls in the style @ali-ramadhan proposed. It's based on Logging.SimpleLogger. I am running into some trouble with Julia not finding my definitions of the functions associated with AbstractLogger though.
Additional log levels can be defined if there would be interest in something like @diagnostic or @setup.
For ProgressPrinter I think it would be straight forward enough to use either @info or a custom macro to handle progress logging.

Didn't know you could define custom macros like @diagnostic, that would be pretty cool!
What's the error you're getting? Can you post your code in this issue (or open a pull request)? We can help out with debugging!

@arcavaliere There's some discussion about logging at https://github.com/climate-machine/CLIMA/issues/134

Here's the PR.
I'm running into a LoadError: MethodError for min_enabled_level(::ModelLogger). I'm not sure how to rectify that issue. Any help will be appreciated!

Hi guys, please feel free to ping me on all logging-related stuff for CLiMA. I pushed through the logging frontend API which exists in 1.0 and I think it can help you understand your simulations. I'm particularly keen to hear use cases related to CLIMA because it's a large scale code with several modules running in a distributed execution environment. Some new logging backend components will need to be invented to make this work well but I think the existing logging frontend is a solid foundation to build on.
Regarding live tracking of simulation progress, a couple of points:

The logging system is designed for exactly this kind of thing - it should slot in nicely
For graphs you could check out TensorBoardLogger. It's designed for ML applications, but the core need seems similar: TensorBoard is a log aggregator which provides rich graphical display for certain data types and can run on the cluster where the compute is happening.
MicroLogging master contains some utilities to make progress reporting nicer so you could check those out. There's also ProgressLogging.jl which does something similar. (Eventually we should to consolidate some of these tools.)

Hi @c42f thank you for chiming in! Will definitely ping you as we work on logging.
I think we probably should have tackled logging much earlier. We still use @printf and vanilla @info for logging, which has been quite counter-productive haha.
Definitely hoping we can reach a useful logger that can

help developers by providing info and debug messages. Also nice in test logs.
help users understand what the model is doing and provide a better and more responsive user experience by logging what the model is doing. This is where @setup and @diagnostic logging messages might be really nice.

Although @setup and @diagnostic might be bad names as they don't imply logging? Not sure of the best solution but maybe your kwarg suggestion would help here, e.g. @info source="diagnostic" msg?
@arcavaliere seems to be developing a pretty general-purpose ModelLogger which hopefully we can adapt for all these uses! @arcavaliere I'm more than happy to help if you need anything.
MicroLogging.jl looks pretty neat! I like that it puts the log level, file name, and line number on the right as putting them on the left causes messages not to align and makes logs harder to read.
TensorBoardLogger looks pretty cool! Would be awesome to have something like that one day, but I guess you'd have to use something like ncusrses...

I updated the PR with @diagnostic and @setup as suggested here. Would you like me to work on porting the formatting from MicroLogging & Logging.ConsoleLogger over the ModelLogger next? Or is the getting the PrintableDiagnostic struct created and usable the next priority?

That's awesome, thanks @arcavaliere!
I think if we can get a printing format similar to MicroLogging.jl with a timestamp on the left and log level + line location then we'll have a great logger we can merge into the code and start using!
And once we start using it we can tweak and improve it as we learn more.
But let me know if you had other features in mind!

I do think @diagnostic and @setup are just @info level logging because they describe normal state changes in your application.
As you can see over on the Base repo, there's ongoing debate about exactly what the _group keyword is for, but you could experiment with _group=:diagnostic or _group=:setup and see how that feels.

I like that it puts the log level, file name, and line number on the right as putting them on the left causes messages not to align and makes logs harder to read.

By the way, this is available in stdlib Logging.ConsoleLogger, but it's hidden behind the right_justify keyword and I'm not sure anyone uses it! I had a long debate about this when putting this code into Base, which I lost ;-) (TBH I'm happy with the outcome because having people copy and paste log messages which are right-justified to a particular terminal width would have led to rather a mess.)

I do think @diagnostic and @setup are just @info level logging because they describe normal state changes in your application.

Just reading the code, I see you've assigned them different importance levels. So perhaps I'm wrong!

Resolved by @arcavaliere in PR #478 :tada:

authors: ali-ramadhan arcavaliere c42f glwagner


text:
ESXi Support?

Hi :)
I'm using this amazing lab on my VMware Workstation and was wondering if it's possible to use the provider plugin vmware_esxi as well as vmware_desktop, in order to deploy to ESXi servers.
This plugin can be seen here:
https://github.com/josenk/vagrant-vmware-esxi
Thanks!
Dviros

Hey @Dviros - I looked into this awhile back, but due to the differences in the way people like to structure their networks with ESXi I couldn't really think of a way to "standardize" the configuration in a way that would work for many people. The easiest way for me was to use Workstation/Fusion to export the completed VMs to ESXi and run them from there.
If you have ideas or want to submit a PR, feel free!

Thanks a lot @clong for the response. Will try to  build a working script on my end :)

Hi @clong! Please check out this pull request ( https://github.com/clong/DetectionLab/pull/199 ).
Key main issues:

All machines needs to be with a vSwitch that has an external NIC to the WAN.
I've added a DHCP machine in order to reserve the MAC addresses to IP's, and assign addresses on the fly. One of the issues was that the script was unable to get the machine's state as it didn't got any IP, ending in an error.
I've experimented with RSYNC and NFS on the Windows machines. Will need some help with this :)

Thanks again!
Dviros

This is exciting! Looking to deploy this in an edu lab environment and would love the opportunity to use @clong's work. Please let me know if you need any help, @Dviros

This is exciting! Looking to deploy this in an edu lab environment and would love the opportunity to use @clong's work. Please let me know if you need any help, @Dviros

Hey @puzzlepeaches  and @clong ,
I've created a new PR:
https://github.com/clong/DetectionLab/pull/234
Thanks a lot :)

Moving this to the wishlist: https://github.com/clong/DetectionLab/wiki/Wishlist

source: gharchive/issue

authors: Dviros clong puzzlepeaches

repo: clong/DetectionLab

license: MIT

license_type: permissive

license_source: github-api


text:
Fix bash syntax highlighting

Fixes #273

Thank you @bourdakos1
I've reverted the version bump and changelog here, and opened #275. Let me know if you need me to change anything else!

source: gharchive/pull-request

repo: cloud-annotations/docusaurus-openapi


text:
Issues provisioning datasources on Grafana in private subnet

All API calls use grafana_url as the base, however if Grafana is being provisioned on a server in a private subnet the public grafana_url may not always line up with the Grafana server DNS in the private subnet.
Example set up:

web-server Nginx on server in public subnet, reverse proxying https://monitoring.app.com/grafana to http://monitoring.production.app.com:3000
public monitoring.app.com is accessed from browser, resolved via public hosted zone
private monitoring.production.app.com is accessed by servers in the VPC, resolved via private hosted zone
grafana-server Grafana running on monitoring.production.app.com in the same VPC in a private subnet, exposing port 3000.

When running ansible-playbook, API calls get made to monitoring.app.com/grafana (configured via grafana_url) which is not correct. API calls should be made to monitoring.production.app.com
Open to solutions and also happy to open a PR after deciding how to handle this, maybe another variable grafana_api_url that can override grafana_url and is used for the API calls?

Adding grafana_api_url with default value of {{ grafana_url }} is a way to go. I don't see any other option which could work in this setup.
Could you create PR?

authors: paulfantom thejchap

repo: cloudalchemy/ansible-grafana


text:
🛑 cbn.id is down

In eb461a1, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in 2699e44.

repo: cloudbip/upptime


text:
🛑 rad.net.id is down

In f49d556, rad.net.id (http://rad.net.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: rad.net.id is back up in e74ecad.


text:
🛑 console.idcloudhost.com is down

In 9ea1b34, console.idcloudhost.com (https://console.idcloudhost.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: console.idcloudhost.com is back up in 0d9f161.


text:
🛑 cbn.id is down

In 6acfc82, cbn.id (https://cbn.id) was down:

HTTP code: 0
Response time: 0 ms

Resolved: cbn.id is back up in dc413d6.


text:
Fixes to make security work

Josh, these were some minor fixes I made to make the Kerberos security integration work; IIRC the problem was an NPE as yarnClient hadn't been initialised yet.

Thanks Craig! As an FYI, I'm going to be out on paternity leave the rest of this week and into next. Will probably be back online again around the 14th.

authors: cmacdonald jwills

repo: cloudera/kitten

license_source: bigquery


text:
allow token based access

Allow token based access to cloudexplain. One should hand over a token, e.g.
with cloudexplain.azure.explain(..., token=token):
    ...

and the upload works.
The token must be resolved in the background (potentially via an azure function) and then a SAS token to the storage account must be returned.

Potentially helpful:
https://learn.microsoft.com/en-us/python/api/azure-core/azure.core.credentials.tokencredential?view=azure-python

repo: cloudexplain/cloudexplain


text:
[DO] Add "get started" video series

Summary

Screenshots (optional)

Documentation checklist

[ ] The documentation style guide has been adhered to.
[ ] If a larger change - such as adding a new page- an issue has been opened in relation to any incorrect or out of date information that this PR fixes.
[ ] Files which have changed name or location have been allocated redirects.

cc: @megaconfidence

Thanks @kodster28. Is there any action needed from me?

Thanks @kodster28. Is there any action needed from me?

Nope!! Should be pushing this live shortly

repo: cloudflare/cloudflare-docs


text:
[Docs Site] Change all internal links to relative

Changes absolute internal links to be relative - mainly because they're annoying when on preview links (or forks) as they take you away and onto the main site but partly because I think the style guide wants them to be relative anyways.
Please spot-check for any malformed links. This commit doesn't include other links, like sub notes, just ones that are part of a Markdown link.

This branch was built at https://kian-relative-links.cloudflare-docs-github.pages.dev and can be used for testing links - I've tested some API links to ensure they work the same as the production site.

I now understand why the /api/ links wasn't relative - because the link checker can't validate them in CI.

Let me take a bit of time later today and push up some logic for this.
Already doing it with some of our links in the /support/ tile, so it shouldn't be that hard to do the same for anything starting with /api/.

@KianNH, if you merge in production, this issue should be fixed.

We'll spot-check review this tomorrow, btw.

Sounds good to me - there's a few ones that I'm a little confused about (i.e D1 & Queues) where the links have always been invalid, but not picked up.
Does it only validate relative links & assumes absolute links are external?
I cleaned up a few links in the support category too - mostly the troubleshooting 1xxx page.

Haha, and by tomorrow, I meant during this lunch break.
Yeah, our link validation doesn't evaluate absolute URLs (we have an SEO crawler tool that does that), so it only "realized" they were broken once they became relative.
It also ignores redirects for easier maintenance down the road.


text:
x-real-ip headers missing in workers

Hi,
The x-real-ip header (documented here) is missing in requests to workers. There are a few other headers listed there which I assume are also missing.
It looks like some cloudflare specific headers are added here, but only ones that are forwarded to original hosts, not headers that only get sent to workers.
I haven't read the code base in any detail, but I assume just adding these headers there would also forward them to upstream, which in the case of at least x-real-ip would be incorrect.
For now I'm just going to work around this locally, so at least from my perspective there's no urgency in fixing this, but I thought I should let you know.

Awesome, thanks :)

repo: cloudflare/miniflare


text:
h3: store all received SETTINGS parameters and expose them

SETTINGS frames can contain parameters with unknown or reserved identifiers.
quiche has no direct usage for these parameters and previously discarded them.
With this change we store all received parameters in the order that they were
sent, and add a new peer_settings_raw() to access them,

applied suggestions, cheers

repo: cloudflare/quiche


text:
requested_validity in cloudflare_origin_ca_certificate is ignored as an input

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.1.5
on darwin_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.8.0
+ provider registry.terraform.io/digitalocean/digitalocean v2.17.1
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/tls v3.1.0
+ provider registry.terraform.io/okta/okta v3.21.0

Affected resource(s)

cloudflare_origin_ca_certificate

Terraform configuration files
terraform {
  required_version = "~> 1.1.5"

  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 3.8.0"
    }

    tls = {
      source  = "hashicorp/tls"
      version = "~> 3.1.0"
    }
  }
}

provider "cloudflare" {}

resource "tls_private_key" "app" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

resource "tls_cert_request" "app" {
  key_algorithm   = tls_private_key.app.algorithm
  private_key_pem = tls_private_key.app.private_key_pem

  subject {
    common_name    = "Cloudflare Origin Certificate"
    street_address = []
  }
}

resource "cloudflare_origin_ca_certificate" "app" {
  csr = tls_cert_request.app.cert_request_pem

  request_type       = "origin-rsa"
  requested_validity = "730"

  hostnames = [
    "raccoon.team",
  ]
}

Debug output
$ TF_LOG=DEBUG terraform plan -out=app.plan
2022-02-13T21:58:25.101-0600 [INFO]  Terraform version: 1.1.5
2022-02-13T21:58:25.102-0600 [INFO]  Go runtime version: go1.17.6
2022-02-13T21:58:25.102-0600 [INFO]  CLI args: []string{"terraform", "plan", "-out=app.plan"}
2022-02-13T21:58:25.102-0600 [DEBUG] Attempting to open CLI config file: /Users/atlas/.terraformrc
2022-02-13T21:58:25.102-0600 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-02-13T21:58:25.102-0600 [INFO]  Loading CLI configuration from /Users/atlas/.terraform.d/credentials.tfrc.json
2022-02-13T21:58:25.102-0600 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-02-13T21:58:25.102-0600 [DEBUG] ignoring non-existing provider search directory /Users/atlas/.terraform.d/plugins
2022-02-13T21:58:25.102-0600 [DEBUG] ignoring non-existing provider search directory /Users/atlas/Library/Application Support/io.terraform/plugins
2022-02-13T21:58:25.102-0600 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2022-02-13T21:58:25.102-0600 [INFO]  CLI command args: []string{"plan", "-out=app.plan"}
2022-02-13T21:58:25.103-0600 [DEBUG] New state was assigned lineage "410aeb0f-8f16-6c77-bef4-b5ca43c63c42"
2022-02-13T21:58:25.194-0600 [DEBUG] checking for provisioner in "."
2022-02-13T21:58:25.208-0600 [DEBUG] checking for provisioner in "/usr/local/bin"
2022-02-13T21:58:25.208-0600 [INFO]  backend/local: starting Plan operation
2022-02-13T21:58:25.209-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:25.209-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:25.218-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0]
2022-02-13T21:58:25.221-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80165
2022-02-13T21:58:25.221-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0
2022-02-13T21:58:25.231-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: configuring server automatic mTLS: timestamp=2022-02-13T21:58:25.231-0600
2022-02-13T21:58:25.241-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:25.241-0600 [DEBUG] provider.terraform-provider-cloudflare_v3.8.0: plugin address: network=unix address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin3693132767 timestamp=2022-02-13T21:58:25.241-0600
2022-02-13T21:58:25.261-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:25.262-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80165
2022-02-13T21:58:25.262-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:25.262-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:25.262-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:25.270-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 args=[.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5]
2022-02-13T21:58:25.272-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80166
2022-02-13T21:58:25.272-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5
2022-02-13T21:58:25.280-0600 [INFO]  provider.terraform-provider-tls_v3.1.0_x5: configuring server automatic mTLS: timestamp=2022-02-13T21:58:25.280-0600
2022-02-13T21:58:25.315-0600 [DEBUG] provider.terraform-provider-tls_v3.1.0_x5: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin004137309 network=unix timestamp=2022-02-13T21:58:25.315-0600
2022-02-13T21:58:25.315-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:25.340-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:25.341-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80166
2022-02-13T21:58:25.341-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:25.341-0600 [DEBUG] Building and walking validate graph
2022-02-13T21:58:25.341-0600 [DEBUG] ProviderTransformer: "tls_private_key.app" (*terraform.NodeValidatableResource) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:25.341-0600 [DEBUG] ProviderTransformer: "tls_cert_request.app" (*terraform.NodeValidatableResource) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:25.341-0600 [DEBUG] ProviderTransformer: "cloudflare_origin_ca_certificate.app" (*terraform.NodeValidatableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-13T21:58:25.341-0600 [DEBUG] ReferenceTransformer: "tls_cert_request.app" references: [tls_private_key.app tls_private_key.app]
2022-02-13T21:58:25.341-0600 [DEBUG] ReferenceTransformer: "cloudflare_origin_ca_certificate.app" references: [tls_cert_request.app]
2022-02-13T21:58:25.341-0600 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/hashicorp/tls\"]" references: []
2022-02-13T21:58:25.341-0600 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" references: []
2022-02-13T21:58:25.341-0600 [DEBUG] ReferenceTransformer: "tls_private_key.app" references: []
2022-02-13T21:58:25.342-0600 [DEBUG] Starting graph walk: walkValidate
2022-02-13T21:58:25.342-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:25.342-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:25.351-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0]
2022-02-13T21:58:25.353-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80167
2022-02-13T21:58:25.353-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0
2022-02-13T21:58:25.364-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: configuring server automatic mTLS: timestamp=2022-02-13T21:58:25.363-0600
2022-02-13T21:58:25.374-0600 [DEBUG] provider.terraform-provider-cloudflare_v3.8.0: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin352335451 network=unix timestamp=2022-02-13T21:58:25.374-0600
2022-02-13T21:58:25.374-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:25.388-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:25.388-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:25.397-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 args=[.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5]
2022-02-13T21:58:25.399-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80168
2022-02-13T21:58:25.400-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5
2022-02-13T21:58:25.408-0600 [INFO]  provider.terraform-provider-tls_v3.1.0_x5: configuring server automatic mTLS: timestamp=2022-02-13T21:58:25.408-0600
2022-02-13T21:58:25.445-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:25.445-0600 [DEBUG] provider.terraform-provider-tls_v3.1.0_x5: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin784772455 network=unix timestamp=2022-02-13T21:58:25.445-0600
2022-02-13T21:58:25.471-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:25.472-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80168
2022-02-13T21:58:25.472-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:25.480-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:25.481-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80167
2022-02-13T21:58:25.481-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:25.481-0600 [INFO]  backend/local: plan calling Plan
2022-02-13T21:58:25.481-0600 [DEBUG] Building and walking plan graph for NormalMode
2022-02-13T21:58:25.482-0600 [DEBUG] ProviderTransformer: "tls_cert_request.app (expand)" (*terraform.nodeExpandPlannableResource) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:25.482-0600 [DEBUG] ProviderTransformer: "cloudflare_origin_ca_certificate.app (expand)" (*terraform.nodeExpandPlannableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-13T21:58:25.482-0600 [DEBUG] ProviderTransformer: "tls_private_key.app (expand)" (*terraform.nodeExpandPlannableResource) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:25.482-0600 [DEBUG] ReferenceTransformer: "tls_private_key.app (expand)" references: []
2022-02-13T21:58:25.482-0600 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/hashicorp/tls\"]" references: []
2022-02-13T21:58:25.482-0600 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" references: []
2022-02-13T21:58:25.482-0600 [DEBUG] ReferenceTransformer: "tls_cert_request.app (expand)" references: [tls_private_key.app (expand) tls_private_key.app (expand)]
2022-02-13T21:58:25.482-0600 [DEBUG] ReferenceTransformer: "cloudflare_origin_ca_certificate.app (expand)" references: [tls_cert_request.app (expand)]
2022-02-13T21:58:25.482-0600 [DEBUG] Starting graph walk: walkPlan
2022-02-13T21:58:25.482-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:25.482-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:25.490-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 args=[.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5]
2022-02-13T21:58:25.492-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80169
2022-02-13T21:58:25.492-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5
2022-02-13T21:58:25.500-0600 [INFO]  provider.terraform-provider-tls_v3.1.0_x5: configuring server automatic mTLS: timestamp=2022-02-13T21:58:25.500-0600
2022-02-13T21:58:25.537-0600 [DEBUG] provider.terraform-provider-tls_v3.1.0_x5: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin158476876 network=unix timestamp=2022-02-13T21:58:25.537-0600
2022-02-13T21:58:25.537-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:25.561-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:25.561-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:25.568-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0]
2022-02-13T21:58:25.571-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80170
2022-02-13T21:58:25.571-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0
2022-02-13T21:58:25.579-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: configuring server automatic mTLS: timestamp=2022-02-13T21:58:25.579-0600
2022-02-13T21:58:25.589-0600 [DEBUG] provider.terraform-provider-cloudflare_v3.8.0: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin2509772301 network=unix timestamp=2022-02-13T21:58:25.589-0600
2022-02-13T21:58:25.589-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:25.604-0600 [DEBUG] Resource instance state not found for node "tls_private_key.app", instance tls_private_key.app
2022-02-13T21:58:25.604-0600 [DEBUG] ReferenceTransformer: "tls_private_key.app" references: []
2022-02-13T21:58:25.604-0600 [DEBUG] refresh: tls_private_key.app: no state, so not refreshing
2022-02-13T21:58:25.605-0600 [WARN]  Provider "registry.terraform.io/hashicorp/tls" produced an invalid plan for tls_private_key.app, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .ecdsa_curve: planned value cty.StringVal("P224") for a non-computed attribute
2022-02-13T21:58:25.605-0600 [DEBUG] Resource instance state not found for node "tls_cert_request.app", instance tls_cert_request.app
2022-02-13T21:58:25.606-0600 [DEBUG] ReferenceTransformer: "tls_cert_request.app" references: []
2022-02-13T21:58:25.606-0600 [DEBUG] refresh: tls_cert_request.app: no state, so not refreshing
2022-02-13T21:58:25.608-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:25.609-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80169
2022-02-13T21:58:25.609-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:25.618-0600 [WARN]  ValidateProviderConfig from "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" changed the config value, but that value is unused
2022-02-13T21:58:25.618-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:25 [INFO] Cloudflare Client configured for user:: timestamp=2022-02-13T21:58:25.618-0600
2022-02-13T21:58:25.618-0600 [DEBUG] Resource instance state not found for node "cloudflare_origin_ca_certificate.app", instance cloudflare_origin_ca_certificate.app
2022-02-13T21:58:25.619-0600 [DEBUG] ReferenceTransformer: "cloudflare_origin_ca_certificate.app" references: []
2022-02-13T21:58:25.619-0600 [DEBUG] refresh: cloudflare_origin_ca_certificate.app: no state, so not refreshing
2022-02-13T21:58:25.620-0600 [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_origin_ca_certificate.app, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .requested_validity: planned value cty.UnknownVal(cty.Number) does not match config value cty.NumberIntVal(730)
2022-02-13T21:58:25.621-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:25.622-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80170
2022-02-13T21:58:25.622-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:25.622-0600 [INFO]  backend/local: plan operation completed
2022-02-13T21:58:25.622-0600 [INFO]  backend/local: writing plan output to: app.plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  + create

Terraform will perform the following actions:

  # cloudflare_origin_ca_certificate.app will be created
  + resource "cloudflare_origin_ca_certificate" "app" {
      + certificate        = (known after apply)
      + csr                = (known after apply)
      + expires_on         = (known after apply)
      + hostnames          = [
          + "raccoon.team",
        ]
      + id                 = (known after apply)
      + request_type       = "origin-rsa"
      + requested_validity = (known after apply)
    }

  # tls_cert_request.app will be created
  + resource "tls_cert_request" "app" {
      + cert_request_pem = (known after apply)
      + id               = (known after apply)
      + key_algorithm    = "RSA"
      + private_key_pem  = (sensitive value)

      + subject {
          + common_name    = "Cloudflare Origin Certificate"
          + street_address = []
        }
    }

  # tls_private_key.app will be created
  + resource "tls_private_key" "app" {
      + algorithm                  = "RSA"
      + ecdsa_curve                = "P224"
      + id                         = (known after apply)
      + private_key_pem            = (sensitive value)
      + public_key_fingerprint_md5 = (known after apply)
      + public_key_openssh         = (known after apply)
      + public_key_pem             = (known after apply)
      + rsa_bits                   = 2048
    }

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

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Saved the plan to: app.plan

To perform exactly these actions, run the following command to apply:
    terraform apply "app.plan"

$ TF_LOG=DEBUG terraform apply app.plan
2022-02-13T21:58:33.289-0600 [INFO]  Terraform version: 1.1.5
2022-02-13T21:58:33.289-0600 [INFO]  Go runtime version: go1.17.6
2022-02-13T21:58:33.289-0600 [INFO]  CLI args: []string{"terraform", "apply", "app.plan"}
2022-02-13T21:58:33.289-0600 [DEBUG] Attempting to open CLI config file: /Users/atlas/.terraformrc
2022-02-13T21:58:33.289-0600 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-02-13T21:58:33.289-0600 [INFO]  Loading CLI configuration from /Users/atlas/.terraform.d/credentials.tfrc.json
2022-02-13T21:58:33.289-0600 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-02-13T21:58:33.289-0600 [DEBUG] ignoring non-existing provider search directory /Users/atlas/.terraform.d/plugins
2022-02-13T21:58:33.289-0600 [DEBUG] ignoring non-existing provider search directory /Users/atlas/Library/Application Support/io.terraform/plugins
2022-02-13T21:58:33.289-0600 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2022-02-13T21:58:33.289-0600 [INFO]  CLI command args: []string{"apply", "app.plan"}
2022-02-13T21:58:33.381-0600 [DEBUG] checking for provisioner in "."
2022-02-13T21:58:33.396-0600 [DEBUG] checking for provisioner in "/usr/local/bin"
2022-02-13T21:58:33.397-0600 [INFO]  backend/local: starting Apply operation
2022-02-13T21:58:33.398-0600 [INFO]  backend/local: apply calling Apply
2022-02-13T21:58:33.398-0600 [DEBUG] Building and walking apply graph for NormalMode plan
2022-02-13T21:58:33.399-0600 [DEBUG] Resource state not found for node "cloudflare_origin_ca_certificate.app", instance cloudflare_origin_ca_certificate.app
2022-02-13T21:58:33.399-0600 [DEBUG] Resource state not found for node "tls_private_key.app", instance tls_private_key.app
2022-02-13T21:58:33.399-0600 [DEBUG] Resource state not found for node "tls_cert_request.app", instance tls_cert_request.app
2022-02-13T21:58:33.399-0600 [DEBUG] ProviderTransformer: "tls_private_key.app" (*terraform.NodeApplyableResourceInstance) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:33.399-0600 [DEBUG] ProviderTransformer: "tls_cert_request.app" (*terraform.NodeApplyableResourceInstance) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:33.399-0600 [DEBUG] ProviderTransformer: "cloudflare_origin_ca_certificate.app" (*terraform.NodeApplyableResourceInstance) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-13T21:58:33.399-0600 [DEBUG] ProviderTransformer: "tls_private_key.app (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:33.399-0600 [DEBUG] ProviderTransformer: "tls_cert_request.app (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/hashicorp/tls"]
2022-02-13T21:58:33.399-0600 [DEBUG] ProviderTransformer: "cloudflare_origin_ca_certificate.app (expand)" (*terraform.nodeExpandApplyableResource) needs provider["registry.terraform.io/cloudflare/cloudflare"]
2022-02-13T21:58:33.399-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:33.399-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:33.410-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 args=[.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5]
2022-02-13T21:58:33.413-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80177
2022-02-13T21:58:33.413-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5
2022-02-13T21:58:33.423-0600 [INFO]  provider.terraform-provider-tls_v3.1.0_x5: configuring server automatic mTLS: timestamp=2022-02-13T21:58:33.423-0600
2022-02-13T21:58:33.462-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:33.462-0600 [DEBUG] provider.terraform-provider-tls_v3.1.0_x5: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin826517524 network=unix timestamp=2022-02-13T21:58:33.462-0600
2022-02-13T21:58:33.488-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:33.489-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80177
2022-02-13T21:58:33.489-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:33.489-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:33.489-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:33.497-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0]
2022-02-13T21:58:33.500-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80178
2022-02-13T21:58:33.500-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0
2022-02-13T21:58:33.510-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: configuring server automatic mTLS: timestamp=2022-02-13T21:58:33.510-0600
2022-02-13T21:58:33.521-0600 [DEBUG] provider.terraform-provider-cloudflare_v3.8.0: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin1091173405 network=unix timestamp=2022-02-13T21:58:33.521-0600
2022-02-13T21:58:33.521-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:33.545-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:33.546-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80178
2022-02-13T21:58:33.546-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "tls_private_key.app (expand)" references: []
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "tls_cert_request.app (expand)" references: []
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "cloudflare_origin_ca_certificate.app (expand)" references: []
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "tls_private_key.app" references: []
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "tls_cert_request.app" references: [tls_private_key.app (expand) tls_private_key.app tls_private_key.app tls_private_key.app (expand) tls_private_key.app tls_private_key.app]
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "cloudflare_origin_ca_certificate.app" references: [tls_cert_request.app (expand) tls_cert_request.app tls_cert_request.app]
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/hashicorp/tls\"]" references: []
2022-02-13T21:58:33.546-0600 [DEBUG] ReferenceTransformer: "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" references: []
2022-02-13T21:58:33.547-0600 [DEBUG] Starting graph walk: walkApply
2022-02-13T21:58:33.547-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:33.547-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:33.557-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0]
2022-02-13T21:58:33.560-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80179
2022-02-13T21:58:33.560-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0
2022-02-13T21:58:33.570-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: configuring server automatic mTLS: timestamp=2022-02-13T21:58:33.570-0600
2022-02-13T21:58:33.581-0600 [DEBUG] provider.terraform-provider-cloudflare_v3.8.0: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin955377971 network=unix timestamp=2022-02-13T21:58:33.581-0600
2022-02-13T21:58:33.581-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:33.594-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:58:33.595-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:58:33.606-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 args=[.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5]
2022-02-13T21:58:33.609-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80180
2022-02-13T21:58:33.609-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5
2022-02-13T21:58:33.611-0600 [WARN]  ValidateProviderConfig from "provider[\"registry.terraform.io/cloudflare/cloudflare\"]" changed the config value, but that value is unused
2022-02-13T21:58:33.619-0600 [INFO]  provider.terraform-provider-tls_v3.1.0_x5: configuring server automatic mTLS: timestamp=2022-02-13T21:58:33.619-0600
2022-02-13T21:58:33.655-0600 [DEBUG] provider.terraform-provider-tls_v3.1.0_x5: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin860289339 network=unix timestamp=2022-02-13T21:58:33.655-0600
2022-02-13T21:58:33.655-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:58:33.679-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:33 [INFO] Cloudflare Client configured for user:: timestamp=2022-02-13T21:58:33.679-0600
2022-02-13T21:58:33.682-0600 [WARN]  Provider "registry.terraform.io/hashicorp/tls" produced an invalid plan for tls_private_key.app, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .ecdsa_curve: planned value cty.StringVal("P224") for a non-computed attribute
tls_private_key.app: Creating...
2022-02-13T21:58:33.682-0600 [INFO]  Starting apply for tls_private_key.app
2022-02-13T21:58:33.682-0600 [DEBUG] tls_private_key.app: applying the planned Create change
tls_private_key.app: Creation complete after 0s [id=c2c9489254aadb8eba0403094b77ad85894f2936]
2022-02-13T21:58:33.879-0600 [WARN]  Provider "registry.terraform.io/hashicorp/tls" produced an invalid plan for tls_cert_request.app, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .private_key_pem: sensitive planned value does not match config value
tls_cert_request.app: Creating...
2022-02-13T21:58:33.879-0600 [INFO]  Starting apply for tls_cert_request.app
2022-02-13T21:58:33.879-0600 [DEBUG] tls_cert_request.app: applying the planned Create change
2022-02-13T21:58:33.882-0600 [WARN]  Provider "provider[\"registry.terraform.io/hashicorp/tls\"]" produced an unexpected new value for tls_cert_request.app, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .subject[0].country: was null, but now cty.StringVal("")
      - .subject[0].locality: was null, but now cty.StringVal("")
      - .subject[0].postal_code: was null, but now cty.StringVal("")
      - .subject[0].province: was null, but now cty.StringVal("")
      - .subject[0].organizational_unit: was null, but now cty.StringVal("")
      - .subject[0].serial_number: was null, but now cty.StringVal("")
      - .subject[0].organization: was null, but now cty.StringVal("")
tls_cert_request.app: Creation complete after 0s [id=fff0044de246e09610017e6a4d257205b0b0af79]
2022-02-13T21:58:33.903-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:33.904-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80180
2022-02-13T21:58:33.904-0600 [DEBUG] provider: plugin exited
2022-02-13T21:58:33.906-0600 [WARN]  Provider "registry.terraform.io/cloudflare/cloudflare" produced an invalid plan for cloudflare_origin_ca_certificate.app, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .requested_validity: planned value cty.UnknownVal(cty.Number) does not match config value cty.NumberIntVal(730)
cloudflare_origin_ca_certificate.app: Creating...
2022-02-13T21:58:33.906-0600 [INFO]  Starting apply for cloudflare_origin_ca_certificate.app
2022-02-13T21:58:33.906-0600 [DEBUG] cloudflare_origin_ca_certificate.app: applying the planned Create change
2022-02-13T21:58:33.907-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:33 [INFO] Creating Cloudflare OriginCACertificate: cloudflare.OriginCACertificate{ID:"", Certificate:"", Hostnames:[]string{"raccoon.team"}, ExpiresOn:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), RequestType:"origin-rsa", RequestValidity:0, RevokedAt:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), CSR:"-----BEGIN CERTIFICATE REQUEST-----\nMIICbTCCAVUCAQAwKDEmMCQGA1UEAxMdQ2xvdWRmbGFyZSBPcmlnaW4gQ2VydGlm\naWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTFAAUDquEAqH6\ng9TjnLm15jlyRCsLPYEcNsRbrM1NM30TPLmt0co3q4fSC7KLk5HgIdeDTQ3XTOgD\nGRP9cSCcUDL0+xQQ5cXbgcmIiJ+kdM/1GgZmJmoXh8N8a1QvG4Xmd5iyJBI6fM0T\nk3sscTNqpX79b4Ua4wSN/6Jr538Jz8yirEQl445/IoNPqHtEZlP+aTfhsr9e7bKv\nqHNO8aIwuD2DwHJ1FbSVXOmhewzsvZoU5nKiS5kxb8Jbnc1Pv1V8QiX2KG6sOmi3\nWM/309jl/bn8SNuZCG2zMgFIuxCD7KlUDoNWpB0/QF/7O1xzncuW0/MPCVoGnDlZ\nX3AM4aDRAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAbyiPwItHL76JTmgmVzW5\nNnifE+b4mIDqLmlJYVpcnU8Q/l0Z26jxFrk/24vgx02Kp9zPMx/re3xys1P/h3pv\ny1MowJcHrzoDrZB+3NC7gJs/7Yv0MG7h8aGiLc3wl9/WLAQlIi6YAakDxqkbDSjM\n+ld4zXRcpq2RhdT5N855DABtIyk8bmMtGTLDjmQttf6UO0ZUcHbjSmZqY+eXjt8Y\n90tDkG8P6B4+NpC/lBnJatbQea6fBwBw6JHWu2hU+cT4GsWv8P912iZnC9puK+vk\nbMRU7MTJoKzpAISpdL41Sz8AylHIrEYHd6vxKKui2pXrTm225DquC0bA5jaY0NEb\n5A==\n-----END CERTIFICATE REQUEST-----\n"}: timestamp=2022-02-13T21:58:33.907-0600
2022-02-13T21:58:33.907-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:33 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
POST /client/v4/certificates HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.5 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.8.0
Content-Length: 1123
Content-Type: application/json
X-Auth-User-Service-Key:
Accept-Encoding: gzip

{
 "id": "",
 "certificate": "",
 "hostnames": [
  "raccoon.team"
 ],
 "expires_on": "0001-01-01T00:00:00Z",
 "request_type": "origin-rsa",
 "requested_validity": 0,
 "revoked_at": "0001-01-01T00:00:00Z",
 "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICbTCCAVUCAQAwKDEmMCQGA1UEAxMdQ2xvdWRmbGFyZSBPcmlnaW4gQ2VydGlm\naWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTFAAUDquEAqH6\ng9TjnLm15jlyRCsLPYEcNsRbrM1NM30TPLmt0co3q4fSC7KLk5HgIdeDTQ3XTOgD\nGRP9cSCcUDL0+xQQ5cXbgcmIiJ+kdM/1GgZmJmoXh8N8a1QvG4Xmd5iyJBI6fM0T\nk3sscTNqpX79b4Ua4wSN/6Jr538Jz8yirEQl445/IoNPqHtEZlP+aTfhsr9e7bKv\nqHNO8aIwuD2DwHJ1FbSVXOmhewzsvZoU5nKiS5kxb8Jbnc1Pv1V8QiX2KG6sOmi3\nWM/309jl/bn8SNuZCG2zMgFIuxCD7KlUDoNWpB0/QF/7O1xzncuW0/MPCVoGnDlZ\nX3AM4aDRAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAbyiPwItHL76JTmgmVzW5\nNnifE+b4mIDqLmlJYVpcnU8Q/l0Z26jxFrk/24vgx02Kp9zPMx/re3xys1P/h3pv\ny1MowJcHrzoDrZB+3NC7gJs/7Yv0MG7h8aGiLc3wl9/WLAQlIi6YAakDxqkbDSjM\n+ld4zXRcpq2RhdT5N855DABtIyk8bmMtGTLDjmQttf6UO0ZUcHbjSmZqY+eXjt8Y\n90tDkG8P6B4+NpC/lBnJatbQea6fBwBw6JHWu2hU+cT4GsWv8P912iZnC9puK+vk\nbMRU7MTJoKzpAISpdL41Sz8AylHIrEYHd6vxKKui2pXrTm225DquC0bA5jaY0NEb\n5A==\n-----END CERTIFICATE REQUEST-----\n"
}
-----------------------------------------------------: timestamp=2022-02-13T21:58:33.907-0600
2022-02-13T21:58:34.471-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:34 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6dd360f8aaf3b5be-MEM
Content-Type: application/json
Date: Mon, 14 Feb 2022 03:58:34 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU4vq74ZFe3sNVUZN1fCJHytfCy; SameSite=Lax; path=/; expires=Mon, 14-Feb-22 06:28:35 GMT; HttpOnly
Set-Cookie: __cfruid=ef49aa50ba6b784fc85a1f1ceac77cfa125ff988-1644811114; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 105

{
 "success": true,
 "result": {
  "id": "610280954938430757279665318466077496955380339098",
  "certificate": "-----BEGIN CERTIFICATE-----\nMIIElDCCA3ygAwIBAgIUauXxyVyEHSIHaFEiWyoTppBmkZowDQYJKoZIhvcNAQEL\nBQAwgYsxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMTQw\nMgYDVQQLEytDbG91ZEZsYXJlIE9yaWdpbiBTU0wgQ2VydGlmaWNhdGUgQXV0aG9y\naXR5MRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlh\nMB4XDTIyMDIxNDAzNTQwMFoXDTM3MDIxMDAzNTQwMFowYjEZMBcGA1UEChMQQ2xv\ndWRGbGFyZSwgSW5jLjEdMBsGA1UECxMUQ2xvdWRGbGFyZSBPcmlnaW4gQ0ExJjAk\nBgNVBAMTHUNsb3VkRmxhcmUgT3JpZ2luIENlcnRpZmljYXRlMIIBIjANBgkqhkiG\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0xQAFA6rhAKh+oPU45y5teY5ckQrCz2BHDbE\nW6zNTTN9Ezy5rdHKN6uH0guyi5OR4CHXg00N10zoAxkT/XEgnFAy9PsUEOXF24HJ\niIifpHTP9RoGZiZqF4fDfGtULxuF5neYsiQSOnzNE5N7LHEzaqV+/W+FGuMEjf+i\na+d/Cc/MoqxEJeOOfyKDT6h7RGZT/mk34bK/Xu2yr6hzTvGiMLg9g8BydRW0lVzp\noXsM7L2aFOZyokuZMW/CW53NT79VfEIl9ihurDpot1jP99PY5f25/EjbmQhtszIB\nSLsQg+ypVA6DVqQdP0Bf+ztcc53LltPzDwlaBpw5WV9wDOGg0QIDAQABo4IBFjCC\nARIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSWyfMfGZ8ec5k5tW6RjeJYAP0FITAf\nBgNVHSMEGDAWgBQk6FNXXXw0QIep65TbuuEWePwppDBABggrBgEFBQcBAQQ0MDIw\nMAYIKwYBBQUHMAGGJGh0dHA6Ly9vY3NwLmNsb3VkZmxhcmUuY29tL29yaWdpbl9j\nYTAXBgNVHREEEDAOggxyYWNjb29uLnRlYW0wOAYDVR0fBDEwLzAtoCugKYYnaHR0\ncDovL2NybC5jbG91ZGZsYXJlLmNvbS9vcmlnaW5fY2EuY3JsMA0GCSqGSIb3DQEB\nCwUAA4IBAQAo1riBViOck2+prmOaZ7kZLCFsAq+6teVy+G4GlcMXqqcU5bUHRMwD\nhREwU9h5ob9WWt05rlvumHyLsIMhr3VCCEmHUxtxWFf71YFolyjyCi8teKxJwfv+\nXRxzvta3DIFYW2CJotMup/eGJ+5FMIqkTCBsQAzrHak4v6O5LtLSmQw+awP/7wD9\n+GXVrxjfEf+unWsZGOOuCtYy+Yn6yGDcdc+rCdEb0eA5JO/OZtI5c7gZYiSw5uHG\nYY5g92L/RiCE3wSqnuER6aAAsNrxevNRpCaLofnX8lLgU/tB5AAg/m7BFOFcD6/O\n0hOlfKA/ejY9yPybvwWKO02KwRd1RENl\n-----END CERTIFICATE-----\n",
  "expires_on": "2037-02-10 03:54:00 +0000 UTC",
  "request_type": "origin-rsa",
  "hostnames": [
   "raccoon.team"
  ],
  "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICbTCCAVUCAQAwKDEmMCQGA1UEAxMdQ2xvdWRmbGFyZSBPcmlnaW4gQ2VydGlm\naWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTFAAUDquEAqH6\ng9TjnLm15jlyRCsLPYEcNsRbrM1NM30TPLmt0co3q4fSC7KLk5HgIdeDTQ3XTOgD\nGRP9cSCcUDL0+xQQ5cXbgcmIiJ+kdM/1GgZmJmoXh8N8a1QvG4Xmd5iyJBI6fM0T\nk3sscTNqpX79b4Ua4wSN/6Jr538Jz8yirEQl445/IoNPqHtEZlP+aTfhsr9e7bKv\nqHNO8aIwuD2DwHJ1FbSVXOmhewzsvZoU5nKiS5kxb8Jbnc1Pv1V8QiX2KG6sOmi3\nWM/309jl/bn8SNuZCG2zMgFIuxCD7KlUDoNWpB0/QF/7O1xzncuW0/MPCVoGnDlZ\nX3AM4aDRAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAbyiPwItHL76JTmgmVzW5\nNnifE+b4mIDqLmlJYVpcnU8Q/l0Z26jxFrk/24vgx02Kp9zPMx/re3xys1P/h3pv\ny1MowJcHrzoDrZB+3NC7gJs/7Yv0MG7h8aGiLc3wl9/WLAQlIi6YAakDxqkbDSjM\n+ld4zXRcpq2RhdT5N855DABtIyk8bmMtGTLDjmQttf6UO0ZUcHbjSmZqY+eXjt8Y\n90tDkG8P6B4+NpC/lBnJatbQea6fBwBw6JHWu2hU+cT4GsWv8P912iZnC9puK+vk\nbMRU7MTJoKzpAISpdL41Sz8AylHIrEYHd6vxKKui2pXrTm225DquC0bA5jaY0NEb\n5A==\n-----END CERTIFICATE REQUEST-----\n",
  "requested_validity": 5475
 },
 "errors": [],
 "messages": []
}

-----------------------------------------------------: timestamp=2022-02-13T21:58:34.471-0600
2022-02-13T21:58:34.472-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:34 [DEBUG] Cloudflare API Request Details:
---[ REQUEST ]---------------------------------------
GET /client/v4/certificates/610280954938430757279665318466077496955380339098 HTTP/1.1
Host: api.cloudflare.com
User-Agent: terraform/1.1.5 terraform-plugin-sdk/2.10.1 terraform-provider-cloudflare/3.8.0
Content-Type: application/json
X-Auth-User-Service-Key:
Accept-Encoding: gzip

-----------------------------------------------------: timestamp=2022-02-13T21:58:34.472-0600
2022-02-13T21:58:34.720-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:34 [DEBUG] Cloudflare API Response Details:
---[ RESPONSE ]--------------------------------------
HTTP/2.0 200 OK
Cf-Cache-Status: DYNAMIC
Cf-Ray: 6dd360fafb91b5b8-MEM
Content-Type: application/json
Date: Mon, 14 Feb 2022 03:58:34 GMT
Expect-Ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
Set-Cookie: __cflb=0H28vgHxwvgAQtjUGU4vq74ZFe3sNVUZN1fCJHytfCy; SameSite=Lax; path=/; expires=Mon, 14-Feb-22 06:28:35 GMT; HttpOnly
Set-Cookie: __cfruid=ef49aa50ba6b784fc85a1f1ceac77cfa125ff988-1644811114; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
Vary: Accept-Encoding
X-Envoy-Upstream-Service-Time: 29

{
 "success": true,
 "result": {
  "id": "610280954938430757279665318466077496955380339098",
  "certificate": "-----BEGIN CERTIFICATE-----\nMIIElDCCA3ygAwIBAgIUauXxyVyEHSIHaFEiWyoTppBmkZowDQYJKoZIhvcNAQEL\nBQAwgYsxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMTQw\nMgYDVQQLEytDbG91ZEZsYXJlIE9yaWdpbiBTU0wgQ2VydGlmaWNhdGUgQXV0aG9y\naXR5MRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlh\nMB4XDTIyMDIxNDAzNTQwMFoXDTM3MDIxMDAzNTQwMFowYjEZMBcGA1UEChMQQ2xv\ndWRGbGFyZSwgSW5jLjEdMBsGA1UECxMUQ2xvdWRGbGFyZSBPcmlnaW4gQ0ExJjAk\nBgNVBAMTHUNsb3VkRmxhcmUgT3JpZ2luIENlcnRpZmljYXRlMIIBIjANBgkqhkiG\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0xQAFA6rhAKh+oPU45y5teY5ckQrCz2BHDbE\nW6zNTTN9Ezy5rdHKN6uH0guyi5OR4CHXg00N10zoAxkT/XEgnFAy9PsUEOXF24HJ\niIifpHTP9RoGZiZqF4fDfGtULxuF5neYsiQSOnzNE5N7LHEzaqV+/W+FGuMEjf+i\na+d/Cc/MoqxEJeOOfyKDT6h7RGZT/mk34bK/Xu2yr6hzTvGiMLg9g8BydRW0lVzp\noXsM7L2aFOZyokuZMW/CW53NT79VfEIl9ihurDpot1jP99PY5f25/EjbmQhtszIB\nSLsQg+ypVA6DVqQdP0Bf+ztcc53LltPzDwlaBpw5WV9wDOGg0QIDAQABo4IBFjCC\nARIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSWyfMfGZ8ec5k5tW6RjeJYAP0FITAf\nBgNVHSMEGDAWgBQk6FNXXXw0QIep65TbuuEWePwppDBABggrBgEFBQcBAQQ0MDIw\nMAYIKwYBBQUHMAGGJGh0dHA6Ly9vY3NwLmNsb3VkZmxhcmUuY29tL29yaWdpbl9j\nYTAXBgNVHREEEDAOggxyYWNjb29uLnRlYW0wOAYDVR0fBDEwLzAtoCugKYYnaHR0\ncDovL2NybC5jbG91ZGZsYXJlLmNvbS9vcmlnaW5fY2EuY3JsMA0GCSqGSIb3DQEB\nCwUAA4IBAQAo1riBViOck2+prmOaZ7kZLCFsAq+6teVy+G4GlcMXqqcU5bUHRMwD\nhREwU9h5ob9WWt05rlvumHyLsIMhr3VCCEmHUxtxWFf71YFolyjyCi8teKxJwfv+\nXRxzvta3DIFYW2CJotMup/eGJ+5FMIqkTCBsQAzrHak4v6O5LtLSmQw+awP/7wD9\n+GXVrxjfEf+unWsZGOOuCtYy+Yn6yGDcdc+rCdEb0eA5JO/OZtI5c7gZYiSw5uHG\nYY5g92L/RiCE3wSqnuER6aAAsNrxevNRpCaLofnX8lLgU/tB5AAg/m7BFOFcD6/O\n0hOlfKA/ejY9yPybvwWKO02KwRd1RENl\n-----END CERTIFICATE-----\n",
  "expires_on": "2037-02-10 03:54:00 +0000 UTC",
  "request_type": "origin-rsa",
  "hostnames": [
   "raccoon.team"
  ]
 },
 "errors": [],
 "messages": []
}

-----------------------------------------------------: timestamp=2022-02-13T21:58:34.720-0600
2022-02-13T21:58:34.720-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: 2022/02/13 21:58:34 [DEBUG] OriginCACertificate: &cloudflare.OriginCACertificate{ID:"610280954938430757279665318466077496955380339098", Certificate:"-----BEGIN CERTIFICATE-----\nMIIElDCCA3ygAwIBAgIUauXxyVyEHSIHaFEiWyoTppBmkZowDQYJKoZIhvcNAQEL\nBQAwgYsxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMTQw\nMgYDVQQLEytDbG91ZEZsYXJlIE9yaWdpbiBTU0wgQ2VydGlmaWNhdGUgQXV0aG9y\naXR5MRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlh\nMB4XDTIyMDIxNDAzNTQwMFoXDTM3MDIxMDAzNTQwMFowYjEZMBcGA1UEChMQQ2xv\ndWRGbGFyZSwgSW5jLjEdMBsGA1UECxMUQ2xvdWRGbGFyZSBPcmlnaW4gQ0ExJjAk\nBgNVBAMTHUNsb3VkRmxhcmUgT3JpZ2luIENlcnRpZmljYXRlMIIBIjANBgkqhkiG\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0xQAFA6rhAKh+oPU45y5teY5ckQrCz2BHDbE\nW6zNTTN9Ezy5rdHKN6uH0guyi5OR4CHXg00N10zoAxkT/XEgnFAy9PsUEOXF24HJ\niIifpHTP9RoGZiZqF4fDfGtULxuF5neYsiQSOnzNE5N7LHEzaqV+/W+FGuMEjf+i\na+d/Cc/MoqxEJeOOfyKDT6h7RGZT/mk34bK/Xu2yr6hzTvGiMLg9g8BydRW0lVzp\noXsM7L2aFOZyokuZMW/CW53NT79VfEIl9ihurDpot1jP99PY5f25/EjbmQhtszIB\nSLsQg+ypVA6DVqQdP0Bf+ztcc53LltPzDwlaBpw5WV9wDOGg0QIDAQABo4IBFjCC\nARIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD\nATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSWyfMfGZ8ec5k5tW6RjeJYAP0FITAf\nBgNVHSMEGDAWgBQk6FNXXXw0QIep65TbuuEWePwppDBABggrBgEFBQcBAQQ0MDIw\nMAYIKwYBBQUHMAGGJGh0dHA6Ly9vY3NwLmNsb3VkZmxhcmUuY29tL29yaWdpbl9j\nYTAXBgNVHREEEDAOggxyYWNjb29uLnRlYW0wOAYDVR0fBDEwLzAtoCugKYYnaHR0\ncDovL2NybC5jbG91ZGZsYXJlLmNvbS9vcmlnaW5fY2EuY3JsMA0GCSqGSIb3DQEB\nCwUAA4IBAQAo1riBViOck2+prmOaZ7kZLCFsAq+6teVy+G4GlcMXqqcU5bUHRMwD\nhREwU9h5ob9WWt05rlvumHyLsIMhr3VCCEmHUxtxWFf71YFolyjyCi8teKxJwfv+\nXRxzvta3DIFYW2CJotMup/eGJ+5FMIqkTCBsQAzrHak4v6O5LtLSmQw+awP/7wD9\n+GXVrxjfEf+unWsZGOOuCtYy+Yn6yGDcdc+rCdEb0eA5JO/OZtI5c7gZYiSw5uHG\nYY5g92L/RiCE3wSqnuER6aAAsNrxevNRpCaLofnX8lLgU/tB5AAg/m7BFOFcD6/O\n0hOlfKA/ejY9yPybvwWKO02KwRd1RENl\n-----END CERTIFICATE-----\n", Hostnames:[]string{"raccoon.team"}, ExpiresOn:time.Date(2037, time.February, 10, 3, 54, 0, 0, time.UTC), RequestType:"origin-rsa", RequestValidity:0, RevokedAt:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), CSR:""}: timestamp=2022-02-13T21:58:34.720-0600
cloudflare_origin_ca_certificate.app: Creation complete after 1s [id=610280954938430757279665318466077496955380339098]
2022-02-13T21:58:34.743-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:58:34.744-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80179
2022-02-13T21:58:34.745-0600 [DEBUG] provider: plugin exited

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

$ TF_LOG=DEBUG terraform state show cloudflare_origin_ca_certificate.app
2022-02-13T21:59:27.938-0600 [INFO]  Terraform version: 1.1.5
2022-02-13T21:59:27.938-0600 [INFO]  Go runtime version: go1.17.6
2022-02-13T21:59:27.938-0600 [INFO]  CLI args: []string{"terraform", "state", "show", "cloudflare_origin_ca_certificate.app"}
2022-02-13T21:59:27.938-0600 [DEBUG] Attempting to open CLI config file: /Users/atlas/.terraformrc
2022-02-13T21:59:27.938-0600 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-02-13T21:59:27.938-0600 [INFO]  Loading CLI configuration from /Users/atlas/.terraform.d/credentials.tfrc.json
2022-02-13T21:59:27.938-0600 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-02-13T21:59:27.938-0600 [DEBUG] ignoring non-existing provider search directory /Users/atlas/.terraform.d/plugins
2022-02-13T21:59:27.938-0600 [DEBUG] ignoring non-existing provider search directory /Users/atlas/Library/Application Support/io.terraform/plugins
2022-02-13T21:59:27.938-0600 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2022-02-13T21:59:27.939-0600 [INFO]  CLI command args: []string{"state", "show", "cloudflare_origin_ca_certificate.app"}
2022-02-13T21:59:27.940-0600 [DEBUG] New state was assigned lineage "bdf51366-4a2d-f8a7-b361-4e89418ad0d0"
2022-02-13T21:59:28.030-0600 [DEBUG] checking for provisioner in "."
2022-02-13T21:59:28.044-0600 [DEBUG] checking for provisioner in "/usr/local/bin"
2022-02-13T21:59:28.046-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:59:28.046-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:59:28.056-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 args=[.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0]
2022-02-13T21:59:28.059-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80207
2022-02-13T21:59:28.059-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0
2022-02-13T21:59:28.070-0600 [INFO]  provider.terraform-provider-cloudflare_v3.8.0: configuring server automatic mTLS: timestamp=2022-02-13T21:59:28.069-0600
2022-02-13T21:59:28.080-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:59:28.080-0600 [DEBUG] provider.terraform-provider-cloudflare_v3.8.0: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin3544501362 network=unix timestamp=2022-02-13T21:59:28.080-0600
2022-02-13T21:59:28.103-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:59:28.104-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/3.8.0/darwin_amd64/terraform-provider-cloudflare_v3.8.0 pid=80207
2022-02-13T21:59:28.104-0600 [DEBUG] provider: plugin exited
2022-02-13T21:59:28.104-0600 [DEBUG] created provider logger: level=debug
2022-02-13T21:59:28.104-0600 [INFO]  provider: configuring client automatic mTLS
2022-02-13T21:59:28.113-0600 [DEBUG] provider: starting plugin: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 args=[.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5]
2022-02-13T21:59:28.115-0600 [DEBUG] provider: plugin started: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80208
2022-02-13T21:59:28.115-0600 [DEBUG] provider: waiting for RPC address: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5
2022-02-13T21:59:28.124-0600 [INFO]  provider.terraform-provider-tls_v3.1.0_x5: configuring server automatic mTLS: timestamp=2022-02-13T21:59:28.123-0600
2022-02-13T21:59:28.158-0600 [DEBUG] provider.terraform-provider-tls_v3.1.0_x5: plugin address: address=/var/folders/f8/jf67cqw15db31zchw9vnb2zw0000gn/T/plugin071868815 network=unix timestamp=2022-02-13T21:59:28.158-0600
2022-02-13T21:59:28.158-0600 [DEBUG] provider: using plugin: version=5
2022-02-13T21:59:28.184-0600 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-02-13T21:59:28.185-0600 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/hashicorp/tls/3.1.0/darwin_amd64/terraform-provider-tls_v3.1.0_x5 pid=80208
2022-02-13T21:59:28.185-0600 [DEBUG] provider: plugin exited
# cloudflare_origin_ca_certificate.app:
resource "cloudflare_origin_ca_certificate" "app" {
    certificate        = <<-EOT
        -----BEGIN CERTIFICATE-----
        MIIElDCCA3ygAwIBAgIUauXxyVyEHSIHaFEiWyoTppBmkZowDQYJKoZIhvcNAQEL
        BQAwgYsxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMTQw
        MgYDVQQLEytDbG91ZEZsYXJlIE9yaWdpbiBTU0wgQ2VydGlmaWNhdGUgQXV0aG9y
        aXR5MRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlh
        MB4XDTIyMDIxNDAzNTQwMFoXDTM3MDIxMDAzNTQwMFowYjEZMBcGA1UEChMQQ2xv
        dWRGbGFyZSwgSW5jLjEdMBsGA1UECxMUQ2xvdWRGbGFyZSBPcmlnaW4gQ0ExJjAk
        BgNVBAMTHUNsb3VkRmxhcmUgT3JpZ2luIENlcnRpZmljYXRlMIIBIjANBgkqhkiG
        9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0xQAFA6rhAKh+oPU45y5teY5ckQrCz2BHDbE
        W6zNTTN9Ezy5rdHKN6uH0guyi5OR4CHXg00N10zoAxkT/XEgnFAy9PsUEOXF24HJ
        iIifpHTP9RoGZiZqF4fDfGtULxuF5neYsiQSOnzNE5N7LHEzaqV+/W+FGuMEjf+i
        a+d/Cc/MoqxEJeOOfyKDT6h7RGZT/mk34bK/Xu2yr6hzTvGiMLg9g8BydRW0lVzp
        oXsM7L2aFOZyokuZMW/CW53NT79VfEIl9ihurDpot1jP99PY5f25/EjbmQhtszIB
        SLsQg+ypVA6DVqQdP0Bf+ztcc53LltPzDwlaBpw5WV9wDOGg0QIDAQABo4IBFjCC
        ARIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
        ATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSWyfMfGZ8ec5k5tW6RjeJYAP0FITAf
        BgNVHSMEGDAWgBQk6FNXXXw0QIep65TbuuEWePwppDBABggrBgEFBQcBAQQ0MDIw
        MAYIKwYBBQUHMAGGJGh0dHA6Ly9vY3NwLmNsb3VkZmxhcmUuY29tL29yaWdpbl9j
        YTAXBgNVHREEEDAOggxyYWNjb29uLnRlYW0wOAYDVR0fBDEwLzAtoCugKYYnaHR0
        cDovL2NybC5jbG91ZGZsYXJlLmNvbS9vcmlnaW5fY2EuY3JsMA0GCSqGSIb3DQEB
        CwUAA4IBAQAo1riBViOck2+prmOaZ7kZLCFsAq+6teVy+G4GlcMXqqcU5bUHRMwD
        hREwU9h5ob9WWt05rlvumHyLsIMhr3VCCEmHUxtxWFf71YFolyjyCi8teKxJwfv+
        XRxzvta3DIFYW2CJotMup/eGJ+5FMIqkTCBsQAzrHak4v6O5LtLSmQw+awP/7wD9
        +GXVrxjfEf+unWsZGOOuCtYy+Yn6yGDcdc+rCdEb0eA5JO/OZtI5c7gZYiSw5uHG
        YY5g92L/RiCE3wSqnuER6aAAsNrxevNRpCaLofnX8lLgU/tB5AAg/m7BFOFcD6/O
        0hOlfKA/ejY9yPybvwWKO02KwRd1RENl
        -----END CERTIFICATE-----
    EOT
    csr                = <<-EOT
        -----BEGIN CERTIFICATE REQUEST-----
        MIICbTCCAVUCAQAwKDEmMCQGA1UEAxMdQ2xvdWRmbGFyZSBPcmlnaW4gQ2VydGlm
        aWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTFAAUDquEAqH6
        g9TjnLm15jlyRCsLPYEcNsRbrM1NM30TPLmt0co3q4fSC7KLk5HgIdeDTQ3XTOgD
        GRP9cSCcUDL0+xQQ5cXbgcmIiJ+kdM/1GgZmJmoXh8N8a1QvG4Xmd5iyJBI6fM0T
        k3sscTNqpX79b4Ua4wSN/6Jr538Jz8yirEQl445/IoNPqHtEZlP+aTfhsr9e7bKv
        qHNO8aIwuD2DwHJ1FbSVXOmhewzsvZoU5nKiS5kxb8Jbnc1Pv1V8QiX2KG6sOmi3
        WM/309jl/bn8SNuZCG2zMgFIuxCD7KlUDoNWpB0/QF/7O1xzncuW0/MPCVoGnDlZ
        X3AM4aDRAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAbyiPwItHL76JTmgmVzW5
        NnifE+b4mIDqLmlJYVpcnU8Q/l0Z26jxFrk/24vgx02Kp9zPMx/re3xys1P/h3pv
        y1MowJcHrzoDrZB+3NC7gJs/7Yv0MG7h8aGiLc3wl9/WLAQlIi6YAakDxqkbDSjM
        +ld4zXRcpq2RhdT5N855DABtIyk8bmMtGTLDjmQttf6UO0ZUcHbjSmZqY+eXjt8Y
        90tDkG8P6B4+NpC/lBnJatbQea6fBwBw6JHWu2hU+cT4GsWv8P912iZnC9puK+vk
        bMRU7MTJoKzpAISpdL41Sz8AylHIrEYHd6vxKKui2pXrTm225DquC0bA5jaY0NEb
        5A==
        -----END CERTIFICATE REQUEST-----
    EOT
    expires_on         = "2037-02-10T03:54:00Z"
    hostnames          = [
        "raccoon.team",
    ]
    id                 = "610280954938430757279665318466077496955380339098"
    request_type       = "origin-rsa"
    requested_validity = 5475
}

Panic output
No response
Expected output
The expected output would be the requested_validity field being set to 730 days in the Terraform plan.
Actual output
The requested_validity parameter is interpreted as a computed field and defaults to 5475 despite being set to 730.
Steps to reproduce

Run a plan action with the requested_validity parameter set to an accepted value besides 5475 (ex: 730).
Verify that the requested_validity in the plan output shows as requested_validity = (known after apply).
Apply the plan and verify that the requested_validity in the Terraform state is not what is expected and has defaulted to 5475.

Additional factoids
No response
References
https://github.com/hashicorp/terraform-plugin-sdk/issues/806
https://github.com/cloudflare/terraform-provider-cloudflare/issues/1276
https://github.com/cloudflare/terraform-provider-cloudflare/issues/1031

Thank you for reporting this issue! For maintainers to dig into issues it is required that all issues include the entirety of TF_LOG=DEBUG output to be provided. The only parts that should be redacted are your user credentials in the X-Auth-Key, X-Auth-Email and Authorization HTTP headers. Details such as zone or account identifiers are not considered sensitive but can be redacted if you are very cautious. This log file provides additional context from Terraform, the provider and the Cloudflare API that helps in debugging issues. Without it, maintainers are very limited in what they can do and may hamper diagnosis efforts.
This issue has been marked with triage/needs-information and is unlikely to receive maintainer attention until the log file is provided making this a complete bug report.

@jacobbednarz Thanks for the heads up! I've updated the issue to include the full debug output for all actions.

thanks @acchiao. it looks like we're sending 0 as the requested validity timespan (and the service is defaulting to the longest) so will need to dig into why that is :/

👋  Is there any progress on this?

I think that this issue was fixed with the PR #1502 and can be closed.

thanks @peruzzof

authors: acchiao jacobbednarz nboaldin peruzzof


text:
[Feature Request] Add an option to make it run as a daemon.

Nothing to add here.

Why not just use systemd with "Type=simple"? Should work just fine.

This feature together with the other one I requested are the bare minimum necessary in order to support utahfs in my project as requested here[1]
[1] https://github.com/mhogomchungu/sirikali/issues/152

Couldn't you just use shell wrapper (potentially with nohup, depending how you want to run it) for that?
e.g.:
#!/bin/sh
nohup utahfs-client -cfg ./utahfs.yaml -mount ./utahfs &

It's possible to do all sort of things but why?, this project is based on fuse and ideally, it should work the same way fuse based projects are expected to work.

It's possible to do all sort of things but why?

I just wanted to provide you with a way that doesn't block you from moving on with your project. I didn't say anything against implementing such a feature. I'm just also curious why someone would have a need for an applications to daemonize itself.
From your rather short starting post "Nothing to add here." I got the impression that you just want to run it as a service in the background, that's why I suggested to use a systemd unit instead.
Sorry, that I cannot know what you were thinking, I can only respond to information one provides.

I'm leaning against this for now. You should indeed use a systemd unit or a shell script. That will let you setup forking, decide where logs go, handle crashes, and create PID files or however you intend to let the user stop the process. Those are all things I don't want pulled into this project.

I just wanted to provide you with a way that doesn't block you from moving on with your project. I didn't say anything against implementing such a feature. I'm just also curious why someone would have a need for an applications to daemonize itself.

This is how FUSE based applications work when they run daemonized.

The application starts.
Applications checks if all conditions necessary to run are satisfied.
If a conditions in step 2 fail, the application prints an error on the terminal and exit with a non zero status result.
If all conditions in step 2 pass, the application branches itself into two parts, one part continues as a daemon and the other part returns with a zero result to signify success.

The point of wanting utahfs to be able to daemonise is because all SiriKali supported backends in Linux and Macos(sshfs, securefs, gocryptfs, cryfs, encfs) have this ability and so far, i have not seen a FUSE based CLI application that does not in Linux.
Initially, i did not add a comment because i didn't think this feature needs convincing and i attributed  a lack of this feature(together with utahfs inability to accept FUSE options) to the youthfulness of this project.

I'm leaning against this for now. You should indeed use a systemd unit or a shell script. That will let you setup forking, decide where logs go, handle crashes, and create PID files or however you intend to let the user stop the process. Those are all things I don't want pulled into this project.

Your comment seems to suggest utahfs will need assistance from systemd or other external tool to run daemonized and that is not the case and it should be able to do so all by itself. All other FUSE based tools do all by themselves.
gocryptfs[1] for example can run daemonized without assistance from any other tool. The main thread seems to fork[2][3] and that is as far i can go since i cant read the language.
My distro of choice does not use systemd and it will be strange to add systemd or any other system logging dependency to SiriKali.
[1] https://github.com/rfjakob/gocryptfs
[2] https://github.com/rfjakob/gocryptfs/blob/3b61244b72f74a25651d4ba184ac7cc62c937db0/main.go#L154
[3] https://github.com/rfjakob/gocryptfs/blob/3b61244b72f74a25651d4ba184ac7cc62c937db0/daemonize.go#L29

It's not clear to me why other tools have support for this either, honestly. It's a lot of work and a sure source of compatibility issues, for an inherently bad user experience. Whether it's systemd or circus or something else, all OSes provide some kind of service manager that provides what you need.

Well, when you run "mount" command to mount a file system, it doesn't hang on success.
Not hanging seems to be the default behavior when mounting file systems and FUSE documentation[1] seems to have daemonization as a default behavior.
[1] https://www.kernel.org/doc/html/latest/filesystems/fuse.html

ntfs-3g[1] is an example of project that is based on FUSE and DOES NOT have an option to run it as a foreground process.
[1]  https://wiki.archlinux.org/index.php/NTFS-3G

@Bren2010 sorry for directly mentioning you, but I don't know if this comment gets read otherwise as the issue is already marked as closed.
I think this request could be rephrased as the following requirement: utahfs should be split into two parts. One main part that handles the long standing stuff, that could be a systemd service that runs as soon as the computer/server starts but does not have any configuration itself. And 2nd a small short lived "mount" command that gets called when the user mounts a utahfs fuse filesystem. This command would be responsible for talking to the background service, letting it create the actual mount and return if the background service completed this operation successfully.
This would render explicit forking obsolet but also allow the command that gets invoked by "mount" to be short lived. What do you think?

Lets revisit how file systems work in linux.
With traditional file systems, you:-

Mount them using "mount" command.
The "mount" command returns immediately.
The mounted file system continue to run in a background.
The mounted file system is unmounted using "umount" command.

With FUSE based file systems like utahfs, the steps should be the same and should be you:-

Mount utahfs file system using "utahfs-client".
The "utahfs-client" command returns immediately.
The utahfs file system continue to run in a background.
The utahfs file system is unmounted using "fusermount" command.

The request here was to make utahfs have a typical behavior of file systems.
Forking and letting the child handle the mounted file system and parent returning immediately is the cleanest solution because:-

It causes utahfs to be self sufficient because it wont need systemd or any other tool to start any part of it.
One instance of utahfs-client will be managing one instance of a running file system. No need for client-server architecture and the associated complexity as suggested by @agowa338
In my local tests here, a process that is running a mounted file system for cryfs, gocryptfs, securefs, sshfs, encfs, fuseiso, ntfs-3g,exfat and  archivemount is owned by a process with a PID of 1 and this suggests all of them are doing the forking dance and the dance is the standard way of doing it.

repo: cloudflare/utahfs


text:
Fix error display for Json variant & add Custom variant

This PR fixes the Display trait implemented for Error and introduces a new variant Custom on the enum.
When implementing custom error handlers, the Display trait implemented for Error on Json variant
Error::Json((msg, status)) => write!(f, "{msg} (status: {status})")

makes it difficult for custom error implementation as the output of the above would look weird.
Here's an example:
let json_string = r#"{ "message": "test", "success": false }"#;
let err = worker::Error::Json((json_string.to_owned(), 500u16));
Response::error(err.to_string(), 500u16)

Outputs:
{ "message": "test", "success": false } (status: 500)

The above doesn't quite serve its purpose for the implemented Display trait.
It looks perfect when the Json variant is written so:
Error::Json((msg, _)) => write!(f, "{msg}")

Outputs:
{
	"message": "test",
	"success": false
}

So, is the point here that Display should output valid JSON, whereas Debug might include the status code?

repo: cloudflare/workers-rs


text:
HttpStartStop filter

The current supported filters do not yet include HttpStartStop. While I understand from https://github.com/cloudfoundry-community/firehose_exporter/issues/1#issuecomment-255870720 that this exporter is designed for a platform operator to collect platform metrics, I believe exporting a subset of the HttpStartStop would be useful:
An operator can currently use the cf apps metrics dashboard to check the metrics for a given app, e.g. to identify a "greedy app" that is using lots of fair cpu cycles.
It seems useful to enrich such per app dashboard for a cf operator platform with data from the HttpStartStop event:

routing traffic request rate (nb requests per second)
routing traffic latency (stopTimestamp - startTimestamp )
routing traffic bandwidth (only contentLength available, i.e. size of response, request size not yet available)
routing traffic distribution on app instances (instanceIndex)
routing traffic error rate (http statusCode)

The associated use-cases for a CF platform operators would be:

drilldown on some aggregated routing metrics when the routing layer is overloaded:

latency 	Time in milliseconds that the Gorouter took to handle requests to its application endpoints. Emitted per router request.
routed_app_requests 	The collector sums up requests for all dea-{index} components for its output metrics. Emitted every 5 seconds.

correlate diego cpu overprovisionning with application reported impacts, such as slow app performance (typically measure with latency of responses on incoming http requests)
troubleshoot unbalanced gorouter load balancing among app instances of a given app (when routing tables are stale/not fresh)
correlate application-reported errors (502 bad gateway status) with diego health management metrics/events

A last use-case I'm studying, is whether exporting HttpStartStop data could be used within the cloudfoundry-community/autosleep service to help get a more reliable measure of the date of last http traffic for a given application. This date is used an indicator of an application inactivity and triggers an automatic stopping the enrolled applications. Autosleep is currently using the recentlogs doppler endpoint. However this has some precision/performance limitations (https://github.com/cloudfoundry-community/autosleep/issues/187 ) that prometheus could help solve (https://github.com/cloudfoundry-community/autosleep/issues/264#issuecomment-262497809 ) if part of the HttpStartStop events would be exported.

@gberche-orange The idea behind this exporter was to behave as a simple proxy to convert Firehose metrics to a Prometheus metrics format. Dealing with HttpStartStop events presents some challenges:

Prometheus is a monitoring and alerting system.  Although it implements a dimensional data model to store its metrics, it's not a time-series database (like InfluxDB or OpenTSDB). This means I cannot simply export the HttpStartStop events as is because this is not how Prometheus works. Prometheus uses a pull model (periodic scrapes), you cannot repeat the same metric with the same labels and different values on a single scrape, and it does not allow sending metrics timestamps.

When exporting ContainerMetrics, CounterEvents and ValueMetrics I took the approach to reporting the last metric gathered from the Firehose, mainly because those metrics are already aggregated/summarized by the Firehose. But this cannot be done for HttpStartStop events because they are not aggregated, they simply report each HTTP request/response (and using 2 different envelopes, one for the client duration and another for the server). This means that I need to aggregate/summarize the HttpStartStop events at the exporter, and this is something that it's out of the scope of my original idea.

Besides the above comments, I understand your problem and agree that it can be really useful to export those metrics. I have been doing some experiments this weekend, and I have implemented a basic prototype that summarizes those events only for application related HTTP requests.
This prototype has also some challenges:

In order to aggregate/summarize the events, I need to store them in memory, and on a highly loaded CF environment, the number of events that needs to be stored and/or aggregated might be quite high. I'm not quite sure how the prototype will behave on such environments, how much memory it will require and if it will be able to handle the firehose throttle.

The way that the exporter emits those events is by summarizing them using quantiles (0.5, 0.9 and 0.99), and this present some challenges when you want to do aggregations. I'd love to have used histograms instead, but this requires configuring the right bucket sizes, and every app might have a different set of requirements, so this means that I need to make the bucket sizes configurable by app, and I believe this is too much complexity for this exporter. Please check the Histograms and Summaries section at the Prometheus documentation to see the challenges of those approaches.

You can check the FAQ to see what metrics are reported now for HttpStartStop events. Please take a look and let me know what do you think. Also, please bear in mind this is the 1st prototype, I still consider it experimental and I may change it completely in the future or just discard it if it does not fulfill our requirements.
I've also started creating some dashboards based on your comments. Please check the cf_apps_*.json files at the Prometheus BOSH release and let me know what do you think.

Thanks a lot @frodenas for this great work! Some initial feedback just reading the code, I hope to provide more relevant feedback once we have actually installed and used the cf_apps_*.json dashboards.

You can check the FAQ to see what metrics are reported now for HttpStartStop events. Please take a look and let me know what do you think

I'm wondering whether the URI label should be kept as this seems a dimension with unbounded high cardinality that might use lots of storage data
Similarly,  the instanceId dimension seems unbounded, whether the instanceIndex seems of much lower cardinality (possibly fitting within 8 or 16 bits unsigned integers)
Related to the duration expressed in seconds, I understand their are computed as float64, and I guess prometheus is able to leverage float64 decimal precisions metrics without loosing nanoseconds resolutions.

Metrics are cached (with a expirity defined at the doppler.metric-expiration command flag). The exporter emits a summary of the HttpStartStop requests not expired using quantiles (0.5, 0.9, 0.99).

How does the caching compares to a potential: the exporter reports metrics summary from sliding window. The sliding window's size doppler.metric-expiration seconds ?

on a highly loaded CF environment, the number of events that needs to be stored and/or aggregated might be quite high. I'm not quite sure how the prototype will behave on such environments, how much memory it will require and if it will be able to handle the firehose throttle.

I agree there are probably too many returned metrics in the current code-base. If I understand correctly, for 1000 apps, with each 5 instances, and each 100 URIs, and 10 status codes, this ends up into 1000510*10=500k * 5 quantile metrics emitted and stored in prometheus every N seconds. Removing the URI dimension will reduce part of it.
We might need to distinguish different types of use-cases:
a- drilldown from routing provided metrics to per app details
b- per app routing metrics (for supporting diagnostic of a specific app, including the autosleep use-case)
c- autosleep
For a) The statusCode and method are probably not necessary. This ends up with 100055=25k quantile metrics emited regularly. Only top N application ids (say top 10 or top 100) might be sufficient to reduce to an acceptable 250-2,500 metrics, making it generally applicable.
For b) (i.e. per app metrics)

it might make sense to support inclusion and exclusion patterns for applications (e.g. based on org names, such as "production" or "premium")

For c) (autosleep)

for the specific case of autosleep, a metric http_start_stop_last_request_timestamp with single dimension/label application_id is useful. In our example with 1,000 active apps, this ends up with 1,000 metrics emitted regulary. If only 100 apps are active, and 9900 are stopped/sleeting, we end up with 100 metrics emitted regulary.

Awesome work @frodenas.  I was thinking about how to get these metrics as well recently, since I think they would be very useful to both devs and operators.
As you mentioned because prometheus is a scrape model and the router metrics are just dumped as a log stream I was thinking of achieving this via a separate workflow:  namely using the firehose-influxdb nozzle to dump them to influx.
The pro of that in my mind would be scalability and granularity of metrics where you aren't having to aggregate or summarize to fit everything in this exporter.  In that model if needed (we're getting close due to firehose throughput) you could scale up multiple nozzles all dumping to the central influx for persistence since the nozzles are just transforming the dataflow.  Not sure how that will work with multiple prometheus exporter nozzles in this project.  Also Grafana could still be used as the dashboard which is nice.
The con is obviously having multiple monitoring systems and not being able to utilize alertmanager for alerts.  Maybe you could have a prometheus exporter that reads these desired metrics from influx rather then directly from the firehose?
I haven't had a chance to try out the httpstartstop improvements you've made here yet but looking forward to it and wanted to add some thoughts to the discussion.

@gberche-orange @poblin-orange As discussed last Friday:

I'm wondering whether the URI label should be kept as this seems a dimension with unbounded high cardinality that might use lots of storage data

Indeed, the HttpStartStop collector returns metrics with too many dimensions. I'm not especially concerned about the storage data, as I haven't seen a huge size increase since I implemented it (and remember that by default, metrics are store only 15 days, configurable by the storage.local.retention property). I'm more concerned about performance issues when querying the data. But I still consider this collector an experiment, and I don't want to limit right now what we may expose as metrics and labels. If later we feel that most of the labels are useless or even harmful, then we can easily drop them.

Similarly, the instanceId dimension seems unbounded, whether the instanceIndex seems of much lower cardinality (possibly fitting within 8 or 16 bits unsigned integers)

During my experiments, the instance index is always 0 regardless of the number of instances and even when having different instance id. This is why I switched to instance id by default. I need to check this with the loggregator team.

Related to the duration expressed in seconds, I understand their are computed as float64, and I guess prometheus is able to leverage float64 decimal precisions metrics without loosing nanoseconds resolutions.

Yes, you will NOT loose ns resolutions. There're plenty of grafana dashboards that show ns resolutions for metrics exposing seconds.

How does the caching compares to a potential: the exporter reports metrics summary from sliding window. The sliding window's sizedoppler.metric-expirationseconds ?

You used a better wording than I :) I updated the FAQ to reflect this.

@mjseid Thanks for your thoughts!
There're basically 3 reasons why I choose Prometheus over InfluxDB:

Prometheus has an already broad set of exporters. When monitoring a CF environment, Elastic Runtime is just one component, and I want to be able to monitor CF's backing storages (etcd, MySQL, Consul, Nats, ...) and even the services that I provide at the marketplace (MySQL, RabbitMQ, Redis, ...). With Prometheus, I was able to archive that without the need to create my own exporters.
I was also really interested in alerting without needing to look for another solution. When I started this project, Grafana didn't have an alerting system (it has been delivered some weeks ago, starting at v4.0.0), and Prometheus provided an HA solution out of the box with multiple configurable receivers.
Similar to 1), I started the Prometheus BOSH release to monitor systems that are outside of the CF community. Later, when playing with it, I realized that creating a firehose exporter was an easy task, so consider this exporter as collateral to my initial goals :)

So far, Prometheus has worked quite well for my goals. Things started to be more challenging when I added the HttpStartStop collector. Basically, because Prometheus is NOT a time series database, and HttpStartStop metrics are returned as a set of events. I'm not against the idea of using another solution for those events if that makes sense, and InfluxDB may be a nicer solution.
w/r/t having multiple nozzles, I'm currently testing this approach (1 firehose exporter per AZ, 1 prometheus server also per AZ, and then a global prometheus server that federates both AZs, something similar to this diagram). It has some challenges, basically because the fact that the loggregator evenly distribute the metrics between the nozzles doesn't help when you need to do aggregation at the nozzle level, but I believe this can be easily solved at the grafana level. But again, I just started testing this.

@gberche-orange I've running the HttpStartStop collector for a while on a medium CF deployment and haven't seen any issue with Prometheus. Although this, I don't feel that having so much cardinality for the uri label is going to help on a high loaded environment. So I've updated the collector to export only the schema and host labels.
I'm closing this issue, but feel free to reopen it if you have any concerns.

authors: frodenas gberche-orange mjseid