Repository navigation
Preserve default transport settings for non-validating clients - #108
Merged
wallyworld merged 4 commits intoAug 19, 2026
Merged
Conversation
Non-validating clients replaced the standard transport while disabling certificate verification, dropping proxy and connection settings. Clone the default transport before changing the TLS configuration. Signed-off-by: Seyeong Kim <seyeong.kim@canonical.com>
There was a problem hiding this comment.
Pull request overview
This PR updates Goose’s non-validating HTTP clients to preserve proxy/connection behavior from Go’s http.DefaultTransport while still disabling TLS certificate verification, addressing Juju upgrade-controller provider precheck failures when a proxy is required.
Changes:
- Introduces
newInsecureHTTPClient()that cloneshttp.DefaultTransport(when it’s an*http.Transport) and setsInsecureSkipVerify. - Ensures non-validating client constructors initialize
opts.insecureHTTPClientwhen not provided via options. - Adds tests verifying default transport settings (e.g., proxy and connection limits) are preserved and not mutated.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
client/client.go |
Builds non-validating HTTP clients by cloning the default transport and only toggling InsecureSkipVerify. |
client/options_test.go |
Adds regression tests around default transport preservation and custom default transport handling. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Signed-off-by: Seyeong Kim <seyeong.kim@canonical.com>
wallyworld
reviewed
Aug 14, 2026
Member
There was a problem hiding this comment.
See my comments - hopefully they make sense.
Signed-off-by: Seyeong Kim <seyeong.kim@canonical.com>
wallyworld
reviewed
Aug 19, 2026
Signed-off-by: Seyeong Kim <seyeong.kim@canonical.com>
3 of 5 tasks
jujubot
pushed a commit
to juju/juju
that referenced
this pull request
Aug 19, 2026
Pick up go-goose/goose#108 so OpenStack provider checks retain proxy transport settings. Related-to: #20141 Signed-off-by: Seyeong Kim <seyeong.kim@canonical.com>
jujubot
added a commit
to juju/juju
that referenced
this pull request
Aug 19, 2026
…heck-3.6 #23080 During controller and model upgrades, Juju performs an OpenStack provider precheck that discovers Keystone authentication options. Goose's non-validating client replaced the default HTTP transport, dropping its proxy and connection settings and attempting to contact Keystone directly. Update `github.com/go-goose/goose/v5` from v5.1.7 to v5.1.8. Goose now uses a common HTTP client constructor for validating and non-validating clients. It clones the default HTTP transport when possible, preserving its proxy and connection settings; only non-validating clients disable TLS certificate verification on the cloned transport. ## Checklist - [x] Code style: imports ordered, good names, simple structure, etc - [ ] ~~Comments saying why design decisions were made~~ - [x] Go unit tests, with comments saying what you're testing - [x] [Integration tests](https://github.com/juju/juju/tree/main/tests), with comments saying what you're testing - [ ] ~~[doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~~ ## QA steps The OpenStack provider unit tests pass with Goose v5.1.8: ```console $ go test ./internal/provider/openstack ok github.com/juju/juju/internal/provider/openstack ``` The Goose change included in v5.1.8 was also tested with a Juju 3.6.19 controller. Direct access from the controller to Keystone was blocked, while requests through the configured HTTP proxy reached Keystone and received its HTTP 300 version-discovery response. Before applying the Goose change, the provider precheck bypassed the proxy: ```console $ juju upgrade-controller -c "$CONTROLLER" \n --dry-run --agent-version=3.6.20 ERROR cannot make API call to provider: Get "http://<keystone>/": dial tcp <keystone>: connect: connection refused ``` Exit code: `1` After upgrading the same controller to an agent built with the Goose change, the same command succeeded under the same proxy and firewall configuration: ```console $ juju upgrade-controller -c "$CONTROLLER" \n --dry-run --agent-version=3.6.20 best version: 3.6.20 upgrade to this version by running juju upgrade-controller ``` Exit code: `0` No facades are changed, so model migration QA is not applicable. ## Documentation changes No user-facing workflow, CLI, or API changes. ## Links **Issue:** Fixes #20141. **Upstream:** [go-goose/goose#108](go-goose/goose#108) **Jira card:** [JUJU-8245](https://warthogs.atlassian.net/browse/JUJU-8245) [JUJU-8245]: https://warthogs.atlassian.net/browse/JUJU-8245?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
jujubot
added a commit
to juju/juju
that referenced
this pull request
Sep 1, 2026
…heck-3.6 #23080 During controller and model upgrades, Juju performs an OpenStack provider precheck that discovers Keystone authentication options. Goose's non-validating client replaced the default HTTP transport, dropping its proxy and connection settings and attempting to contact Keystone directly. Update `github.com/go-goose/goose/v5` from v5.1.7 to v5.1.8. Goose now uses a common HTTP client constructor for validating and non-validating clients. It clones the default HTTP transport when possible, preserving its proxy and connection settings; only non-validating clients disable TLS certificate verification on the cloned transport. - [x] Code style: imports ordered, good names, simple structure, etc - [ ] ~~Comments saying why design decisions were made~~ - [x] Go unit tests, with comments saying what you're testing - [x] [Integration tests](https://github.com/juju/juju/tree/main/tests), with comments saying what you're testing - [ ] ~~[doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~~ The OpenStack provider unit tests pass with Goose v5.1.8: ```console $ go test ./internal/provider/openstack ok github.com/juju/juju/internal/provider/openstack ``` The Goose change included in v5.1.8 was also tested with a Juju 3.6.19 controller. Direct access from the controller to Keystone was blocked, while requests through the configured HTTP proxy reached Keystone and received its HTTP 300 version-discovery response. Before applying the Goose change, the provider precheck bypassed the proxy: ```console $ juju upgrade-controller -c "$CONTROLLER" \n --dry-run --agent-version=3.6.20 ERROR cannot make API call to provider: Get "http://<keystone>/": dial tcp <keystone>: connect: connection refused ``` Exit code: `1` After upgrading the same controller to an agent built with the Goose change, the same command succeeded under the same proxy and firewall configuration: ```console $ juju upgrade-controller -c "$CONTROLLER" \n --dry-run --agent-version=3.6.20 best version: 3.6.20 upgrade to this version by running juju upgrade-controller ``` Exit code: `0` No facades are changed, so model migration QA is not applicable. No user-facing workflow, CLI, or API changes. **Issue:** Fixes #20141. **Upstream:** [go-goose/goose#108](go-goose/goose#108) **Jira card:** [JUJU-8245](https://warthogs.atlassian.net/browse/JUJU-8245) [JUJU-8245]: https://warthogs.atlassian.net/browse/JUJU-8245?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Non-validating clients now preserve proxy and connection settings from the default HTTP transport while still disabling TLS certificate verification.
Related issue: juju/juju#20141
##TEST##
Tested with a Juju 3.6.19 controller using Goose v5.1.4.
Direct access from the controller to Keystone was blocked, while access through the configured HTTP proxy returned HTTP 300.
Before this patch, the provider precheck bypassed the proxy:
Exit code:
1The same controller was then upgraded to an agent built with Goose v5.1.4 plus this patch.
Under the same proxy and firewall configuration, the same command succeeded:
Exit code:
0