Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make timeouts configurable for the PCP transport #2518

Closed
adreyer opened this issue Jan 6, 2021 · 0 comments · Fixed by #2529
Closed

Make timeouts configurable for the PCP transport #2518

adreyer opened this issue Jan 6, 2021 · 0 comments · Fixed by #2529
Assignees
@lucywyman
Labels
Feature New features and improvements.

Comments

@adreyer
Copy link
Contributor

adreyer commented Jan 6, 2021 •
edited by lucywyman
Loading

Use Case

Orchestrator may be slow to respond during a code deploy. Making the timeout easily configurable would provide a workaround.

example timeout

kind: "puppetlabs.tasks/exception-error"
--
issue_code: "EXCEPTION"
msg: "Net::ReadTimeout"
details: {"class":"Faraday::TimeoutError","stack_trace":"/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/protocol.rb:181:in `rbuf_fill'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/protocol.rb:157:in `readuntil'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/protocol.rb:167:in `readline'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/http/response.rb:40:in `read_status_line'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/http/response.rb:29:in `read_new'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/http.rb:1497:in `block in transport_request'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/http.rb:1494:in `catch'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/http.rb:1494:in `transport_request'\
/opt/puppetlabs/bolt/lib/ruby/2.5.0/net/http.rb:1467:in `request'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/net-http-persistent-4.0.0/lib/net/http/persistent.rb:891:in `block in request'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/net-http-persistent-4.0.0/lib/net/http/persistent.rb:606:in `connection_for'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/net-http-persistent-4.0.0/lib/net/http/persistent.rb:885:in `request'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/adapter/net_http_persistent.rb:30:in `perform_request'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/adapter/net_http.rb:38:in `block in call'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/adapter/net_http.rb:85:in `with_net_http_connection'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/adapter/net_http.rb:33:in `call'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/rack_builder.rb:143:in `build_response'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/connection.rb:387:in `run_request'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/faraday-0.14.0/lib/faraday/connection.rb:175:in `post'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/orchestrator_client-0.4.3/lib/orchestrator_client.rb:52:in `post'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/orchestrator_client-0.4.3/lib/orchestrator_client/command.rb:24:in `plan_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/orchestrator_client-0.4.3/lib/orchestrator_client/job.rb:32:in `start'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/orchestrator_client-0.4.3/lib/orchestrator_client.rb:80:in `run_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/transport/orch/connection.rb:82:in `run_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/transport/orch.rb:199:in `run_task_job'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/transport/orch.rb:215:in `batch_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/executor.rb:288:in `block (3 levels) in run_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/executor.rb:249:in `with_node_logging'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/executor.rb:287:in `block (2 levels) in run_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.19.0/lib/bolt/executor.rb:128:in `block (3 levels) in queue_execute'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:348:in `run_task'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:337:in `block (3 levels) in create_worker'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `loop'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:320:in `block (2 levels) in create_worker'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `catch'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/concurrent-ruby-1.1.5/lib/concurrent/executor/ruby_thread_pool_executor.rb:319:in `block in create_worker'\
/opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'"}
  • New read-timeout config for the pcp transport, which configures how long to wait for any HTTP response from the Orchestrator.
  • This will most likely land in orchestrator ruby client. This should not break the existing behavior of the orch client.
@adreyer adreyer added the Feature New features and improvements. label Jan 6, 2021
lucywyman added a commit to lucywyman/bolt that referenced this issue Jan 9, 2021
@lucywyman
(puppetlabsGH-2518) Add read-timeout config for PCP transport
37d8e37 
This adds a `read-timeout` configuration setting for the PCP transport,
which accepts an integer and passes the configuration to
`OrchestratorClient.new()`. Although the option is an integer, it
should be nil if a value is not provided, as there's no static default
for `Net::Http::Persistent#read_timeout`, so we should not set one
unless it's configured. This allows users to configure either failing
quickly if the Orchestrator is busy (such as during code deploys), or to
extend the time if they'd like to wait for the jobs to finish.
`read-timeout` configures the length of time to wait for a response from
the Orchestrator before raising a timeout error when making HTTP
requests.

!feature

* **Add read-timeout configuration option for PCP transport** ([puppetlabs#2518](puppetlabs#2518))

  Users can now configure a `read-timeout` for HTTP requests to the
  Orchestrator, which defines how long to wait for a response before
  raising a Timeout error.
lucywyman added a commit to lucywyman/bolt that referenced this issue Jan 9, 2021
@lucywyman
(puppetlabsGH-2518) Add read-timeout config for PCP transport
87116eb 
This adds a `read-timeout` configuration setting for the PCP transport,
which accepts an integer and passes the configuration to
`OrchestratorClient.new()`. Although the option is an integer, it
should be nil if a value is not provided, as there's no static default
for `Net::Http::Persistent#read_timeout`, so we should not set one
unless it's configured. This allows users to configure either failing
quickly if the Orchestrator is busy (such as during code deploys), or to
extend the time if they'd like to wait for the jobs to finish.
`read-timeout` configures the length of time to wait for a response from
the Orchestrator before raising a timeout error when making HTTP
requests.

!feature

* **Add read-timeout configuration option for PCP transport** ([puppetlabs#2518](puppetlabs#2518))

  Users can now configure a `read-timeout` for HTTP requests to the
  Orchestrator, which defines how long to wait for a response before
  raising a Timeout error.
@lucywyman lucywyman mentioned this issue Jan 9, 2021
Merged
1 task
lucywyman added a commit to lucywyman/bolt that referenced this issue Jan 9, 2021
@lucywyman
(puppetlabsGH-2518) Add read-timeout config for PCP transport
c3ca234 
This adds a `read-timeout` configuration setting for the PCP transport,
which accepts an integer and passes the configuration to
`OrchestratorClient.new()`. Although the option is an integer, it
should be nil if a value is not provided, as there's no static default
for `Net::Http::Persistent#read_timeout`, so we should not set one
unless it's configured. This allows users to configure either failing
quickly if the Orchestrator is busy (such as during code deploys), or to
extend the time if they'd like to wait for the jobs to finish.
`read-timeout` configures the length of time to wait for a response from
the Orchestrator before raising a timeout error when making HTTP
requests.

!feature

* **Add read-timeout configuration option for PCP transport** ([puppetlabs#2518](puppetlabs#2518))

  Users can now configure a `read-timeout` for HTTP requests to the
  Orchestrator, which defines how long to wait for a response before
  raising a Timeout error.
@beechtom beechtom linked a pull request Jan 11, 2021 that will close this issue
(GH-2518) Add read-timeout config for PCP transport #2529
Merged
1 task
lucywyman added a commit to lucywyman/bolt that referenced this issue Jan 13, 2021
@lucywyman
(puppetlabsGH-2518) Add read-timeout config for PCP transport
c1917fe 
This adds a `read-timeout` configuration setting for the PCP transport,
which accepts an integer and passes the configuration to
`OrchestratorClient.new()`. Although the option is an integer, it
should be nil if a value is not provided, as there's no static default
for `Net::Http::Persistent#read_timeout`, so we should not set one
unless it's configured. This allows users to configure either failing
quickly if the Orchestrator is busy (such as during code deploys), or to
extend the time if they'd like to wait for the jobs to finish.
`read-timeout` configures the length of time to wait for a response from
the Orchestrator before raising a timeout error when making HTTP
requests.

!feature

* **Add read-timeout configuration option for PCP transport** ([puppetlabs#2518](puppetlabs#2518))

  Users can now configure a `read-timeout` for HTTP requests to the
  Orchestrator, which defines how long to wait for a response before
  raising a Timeout error.
lucywyman added a commit to lucywyman/bolt that referenced this issue Jan 14, 2021
@lucywyman
(puppetlabsGH-2518) Add read-timeout config for PCP transport
0dfc622 
This adds a `read-timeout` configuration setting for the PCP transport,
which accepts an integer and passes the configuration to
`OrchestratorClient.new()`. Although the option is an integer, it
should be nil if a value is not provided, as there's no static default
for `Net::Http::Persistent#read_timeout`, so we should not set one
unless it's configured. This allows users to configure either failing
quickly if the Orchestrator is busy (such as during code deploys), or to
extend the time if they'd like to wait for the jobs to finish.
`read-timeout` configures the length of time to wait for a response from
the Orchestrator before raising a timeout error when making HTTP
requests.

!feature

* **Add read-timeout configuration option for PCP transport** ([puppetlabs#2518](puppetlabs#2518))

  Users can now configure a `read-timeout` for HTTP requests to the
  Orchestrator, which defines how long to wait for a response before
  raising a Timeout error.
beechtom added a commit that referenced this issue Jan 14, 2021
@beechtom
Merge pull request #2529 from lucywyman/GH-2518
d2a1661 
(GH-2518) Add read-timeout config for PCP transport
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lucywyman lucywyman

Labels
Feature New features and improvements.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

(GH-2518) Add read-timeout config for PCP transport lucywyman/bolt
2 participants
@adreyer @lucywyman