0.87 release planned 🎃

[clux]

Quite a bit in the milestone now and seems like a good time to do another release. particularly since we got a fix in the controller scheduler (and another timeout pass-down "fix")

particular stuff worth highlighting imo:

• socks5
• auth plugin work (although still some WIP there in Provide cluster info to exec plugins #1331)
• Controller::reconcile_on change (breaking, but it's for an unstable interface)
• dep upgrades, syn upgrade caused a break on #[kube(struct)]

will likely hit it up later this evening.

[clux]

ugh, failed mid release:

error[E0425]: cannot find value `connector` in this scope
   --> src/client/builder.rs:123:51
    |
123 |         let mut connector = TimeoutConnector::new(connector);
    |                                                   ^^^^^^^^^ not found in this scope

[clux]

kube-core was the only one that made it through. yanked it to avoid confusing dependabot et al:

cargo yank --version 0.87.0 kube-core
    Updating crates.io index
        Yank [email protected]

[clux]

Ok, we somehow uncovered a fault in CI testing here; cargo test -p kube-client --no-default-features fails. Annoying because we do actually try to do a no-default-feature build of kube (*), just not all the underlying crates...

The problem in this case is the socks5 PR removing these 2 lines: https://github.com/kube-rs/kube/pull/1311/files#diff-1ab2824dd0a6633b63d18104f91fc5e7dfb07bb14a80c956af7b8af33162813bL78-L79 which are not reinstated in the new make_generic_builder for all cases. I.e. we can't create the service anymore in the case of no tls stack. i.e.

Not decided what to do yet for the release. Either we temporarily backout the PR or fix forwards. cc @Razz4780 . In either case, not doing the release tonight.

[Razz4780]

Ok, we somehow uncovered a fault in CI testing here; cargo test -p kube-client --no-default-features fails. Annoying because we do actually try to do a no-default-feature build of kube (*), just not all the underlying crates...

The problem in this case is the socks5 PR removing these 2 lines: https://github.com/kube-rs/kube/pull/1311/files#diff-1ab2824dd0a6633b63d18104f91fc5e7dfb07bb14a80c956af7b8af33162813bL78-L79 which are not reinstated in the new make_generic_builder for all cases. I.e. we can't create the service anymore in the case of no tls stack. i.e.

Not decided what to do yet for the release. Either we temporarily backout the PR or fix forwards. cc @Razz4780 . In either case, not doing the release tonight.

Wait, what exactly is the problem? cargo test -p kube-client --no-default-features works on main. Those two lines are still there in TryFrom<Config> implementation for GenericService. make_generic_builder accepts the base connector as an argument.

[clux]

uh, i think the problem is that the make_generic_builder expects to use the base_connector in one of the feature-flagged lines below in https://github.com/kube-rs/kube/blob/main/kube-client/src/client/builder.rs#L113-L116, but if neither are true, then you don't actually have the connector variable in scope. the cargo test command i wrote does indeed work though 😕

[clux]

this fails at root in main:

cargo test -p kube --no-default-features --features=client

EDIT: but more importantly, build also:

cargo build -p kube --no-default-features --features=client

[Razz4780]

Ah, that's right. #1335 fixes the issue

[clux]

Seems we have both arrived at the same fix: #1334
Appreciate it!

[Razz4780]

Btw. one line in the related code seems fishy - https://github.com/kube-rs/kube/pull/1335/files#diff-1ab2824dd0a6633b63d18104f91fc5e7dfb07bb14a80c956af7b8af33162813bL118

if auth_layer.is_none() || config.cluster_url.scheme() == Some(&http::uri::Scheme::HTTPS) {
    // no tls stack situation only works on anonymous auth with http scheme
    return Err(Error::TlsRequired);
}

I haven't checked the code thoroughly, but based on the comment it seems to me that it should rather be something like

if auth_layer.is_some() || config.cluster_url.scheme() != Some(&http::uri::Scheme::HTTP) {
    // no tls stack situation only works on anonymous auth with http scheme
    return Err(Error::TlsRequired);
}

[clux]

hm, good spot. i think the auth_layer check might be leftover from my initial experiments. i suspect it's a worthless check, and the scheme check is doing all the heavy lifting. the https scheme should be the only necessary condition for triggering the error (you could actually have an auth layer with basic auth without using https - and that shouldn't throw here)

[goenning]

Hi @clux it seems like version 0.86 is yanked, but I could not find any notes on why. This issue only mentions about 0.87 (which is not even listed on crates.io), but what happened to 0.86?

[clux]

Hey @goenning , it was yanked as a result of #1316 (comment) to try to avoid having more people being bitten by that controller bug - linked to that release.