search

Arnavion / k8s-openapi

Rust definitions of the resource types in the Kubernetes client API
Apache License 2.0
373 stars 42 forks source link

error: `None of the v1_* features are enabled on the k8s-openapi crate.` but Cargo.toml specifies the required feature #119

Closed notjames closed 1 year ago

notjames commented 2 years ago

New to Rust - Trying to build a k8s operator. When testing what I have so far, attempting to build causes the above-mentioned error. Thing is, my Cargo.toml does specify the feature. I'm building a bin. A bit of digging and I notice that the build is compiling two different versions of k8s-openapi (v0.14.0 and v0.11.0 - and I'm requesting to use 0.15.0 in my Cargo) so I'm assuming a dep is doing something wrong... I've been through https://docs.rs/k8s-openapi/latest/k8s_openapi/#crate-features and as far as I can tell, I'm doing this right, but I may be missing something.

My Cargo.toml:

[package]
name          = "credrotate-k8s-operator"
version       = "0.0.1"
edition       = "2021"
authors       = ['Jim Conner <me@my.address>']
description   = "K8s Operator Library for credrotate"
rust-version  = "1.62"

[features]
openssl = []

[patch.crates-io]
openssl       = { git = "https://github.com/ishitatsuyuki/rust-openssl", branch = "0.9.x" }

[dependencies]
openssl-sys   = "~0.9"
openssl       = { version = "~0.10", features = ["vendored"] }
openssl-probe = "~0.1.5"

tokio         = { version = "~1.17", features = ["macros", "rt-multi-thread"] }
kube          = { version = "~0.70", default-features = true, features = ["runtime", "derive"] }
k8s-openapi   = { version = "~0.15", features = ["v1_21"] }
kube-derive   = "~0.52"
kube-runtime  = "~0.52"
futures       = "~0.3"
serde         = "~1.0"
serde_json    = "~1.0"
schemars      = "~0.8"
thiserror     = "~1.0"
log4rs        = "1.0.0"
#introspection = "0.1.0"
#introspection-derive = "0.1.0"

[[bin]]
name          = "credrotate-k8s-operator"

The build error:

✦ at 23:07:10 ❯ cargo build
warning: Patch `openssl v0.9.24 (https://github.com/ishitatsuyuki/rust-openssl?branch=0.9.x#3b73dda4)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
   Compiling k8s-openapi v0.14.0
   Compiling ahash v0.7.6
   Compiling humantime v1.3.0
   Compiling serde_json v1.0.81
   Compiling pin-project-internal v0.4.29
   Compiling k8s-openapi v0.11.0
error: failed to run custom build command for `k8s-openapi v0.14.0`

Caused by:
  process didn't exit successfully: `/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator/target/debug/build/k8s-openapi-e310e22dec3ca43a/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.14.0/build.rs:9:42
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `k8s-openapi v0.11.0`

Caused by:
  process didn't exit successfully: `/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator/target/debug/build/k8s-openapi-4ce909515dc1cfbe/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.11.0/build.rs:9:42
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Neither version in this build is the one I'm specifying in Cargo.toml so I'm assuming something is pulling in deps from upstream, but if that's the case, I don't know how I would fix my Cargo.toml in a way that would affect the build for those deps.

Reading around indicates that k8s-openapi is difficult at times. A backtrace shows:

✦ at 23:14:03 ❯ RUST_BACKTRACE=1 cargo build 
warning: Patch `openssl v0.9.24 (https://github.com/ishitatsuyuki/rust-openssl?branch=0.9.x#3b73dda4)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
   Compiling k8s-openapi v0.14.0
   Compiling doc-comment v0.3.3
   Compiling k8s-openapi v0.11.0
   Compiling anyhow v1.0.57
   Compiling unsafe-any v0.4.2
   Compiling k8s-openapi v0.15.0
   Compiling proc-macro2 v1.0.39
error: failed to run custom build command for `k8s-openapi v0.14.0`

Caused by:
  process didn't exit successfully: `/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator/target/debug/build/k8s-openapi-e310e22dec3ca43a/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.14.0/build.rs:9:42
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/panicking.rs:142:14
     2: core::panicking::panic_display
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/panicking.rs:72:5
     3: core::panicking::panic_str
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/panicking.rs:56:5
     4: core::option::expect_failed
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/option.rs:1855:5
     5: core::option::Option<T>::expect
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/option.rs:718:21
     6: build_script_build::main
               at ./build.rs:9:18
     7: core::ops::function::FnOnce::call_once
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/ops/function.rs:248:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `k8s-openapi v0.11.0`

Caused by:
  process didn't exit successfully: `/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator/target/debug/build/k8s-openapi-4ce909515dc1cfbe/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.11.0/build.rs:9:42
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/std/src/panicking.rs:584:5
     1: core::panicking::panic_fmt
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/panicking.rs:142:14
     2: core::panicking::panic_display
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/panicking.rs:72:5
     3: core::panicking::panic_str
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/panicking.rs:56:5
     4: core::option::expect_failed
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/option.rs:1855:5
     5: core::option::Option<T>::expect
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/option.rs:718:21
     6: build_script_build::main
               at ./build.rs:9:18
     7: core::ops::function::FnOnce::call_once
               at /rustc/34a6c9f26e2ce32cad0d71f5e342365b09f4d12c/library/core/src/ops/function.rs:248:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
clux commented 2 years ago

kube needs to depend on an explicit version of k8s-openapi (without features). Your kube version is 0.52 which pulls in k8s-openapi 0.11 (which you haven't selected versions for).

You need to upgrade to the latest kube release if you want to use k8s-openapi 0.15

clux commented 2 years ago

looking more closely at your toml, you are actually pulling in kube components twice (at different versions):

kube          = { version = "~0.70", default-features = true, features = ["runtime", "derive"] }
k8s-openapi   = { version = "~0.15", features = ["v1_21"] }
kube-derive   = "~0.52"
kube-runtime  = "~0.52"

this is probably a mistake, you probably want either:

kube          = { version = "~0.70", features = ["runtime", "derive"] }
k8s-openapi   = { version = "~0.14", features = ["v1_21"] }

or

kube          = { version = "~0.73", features = ["runtime", "derive"] }
k8s-openapi   = { version = "~0.15", features = ["v1_21"] }

and then refer to the exports from kube-runtime/kube-derive via the entry point crate.

notjames commented 2 years ago

@clux thanks for your assistance. I've tried both configurations stated above and neither works, unfortunately.

I even tried removing an entry for k8s-openapi with hopes that kube would pull it in automatically (not sure that would work or not), but that failed.

This is from using 

kube          = { version = "~0.73", features = ["runtime", "derive"] }
k8s-openapi   = { version = "~0.15", features = ["v1_21"] }

here:

$ cargo clean
# edited Cargo.toml
$ cargo build
...
...
   Compiling ahash v0.7.6
error: failed to run custom build command for `k8s-openapi v0.11.0`

Caused by:
  process didn't exit successfully: `/home/me/projects/my/projects/k8s-operators/cred-rotator/operator/target/debug/build/k8s-openapi-4ce909515dc1cfbe/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at '
  None of the v1_* features are enabled on the k8s-openapi crate.

  The k8s-openapi crate requires a feature to be enabled to indicate which version of Kubernetes it should support.

  If you're using k8s-openapi in a binary crate, enable the feature corresponding to the minimum version of API server that you want to support. It may be possible that your binary crate does not directly depend on k8s-openapi. In this case, add a dependency on k8s-openapi, then enable the corresponding feature.

  If you're using k8s-openapi in a library crate, add a dev-dependency on k8s-openapi and enable one of the features there. This way the feature will be enabled when buildings tests and examples of your library, but not when building the library itself. It may be possible that your library crate does not directly depend on k8s-openapi. In this case, add a dev-dependency on k8s-openapi, then enable the corresponding feature.

  Library crates *must not* enable any features in their direct dependency on k8s-openapi, only in their dev-dependency. The choice of Kubernetes version to support should be left to the final binary crate, so only the binary crate should enable a specific feature. If library crates also enable features, it can cause multiple features to be enabled simultaneously, which k8s-openapi does not support.

  If you want to restrict your library crate to support only a single specific version or range of versions of Kubernetes, please use the k8s_* version-specific macros to emit different code based on which feature gets enabled in the end.', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/k8s-openapi-0.11.0/build.rs:9:42
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Noticing that the version failed for build command for k8s-openapi v0.11.0, which confuses me. Maybe I'm missing a step before attempting to build?

clux commented 2 years ago

Something in your dependency tree is pulling in an older version of k8s-openapi. Try to look at cargo tree -i k8s-openapi to see what that is.

Arnavion commented 2 years ago

As the error tells you, you still have k8s-openapi 0.11.0 somewhere in your lockfile, so read it to figure out what's pulling it in.

notjames commented 2 years ago

great pointers...I had to tweak the arguments a little for the cargo tree command...

✦ at 13:01:28 ❯ cargo tree -i k8s-openapi:0.11.0
warning: Patch `openssl v0.9.24 (https://github.com/ishitatsuyuki/rust-openssl?branch=0.9.x#3b73dda4)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
k8s-openapi v0.11.0
├── kube v0.52.0
│   └── kube-runtime v0.52.0
│       └── credrotate-k8s-operator v0.0.1 (/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator)
└── kube-runtime v0.52.0 (*)

└>jimconn on vmlinux in k8s-operators/cred-rotator/operator ・
✦ at 13:01:58 ❯ cargo tree -i k8s-openapi:0.15.0
warning: Patch `openssl v0.9.24 (https://github.com/ishitatsuyuki/rust-openssl?branch=0.9.x#3b73dda4)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
k8s-openapi v0.15.0
├── credrotate-k8s-operator v0.0.1 (/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator)
├── kube v0.73.0
│   └── credrotate-k8s-operator v0.0.1 (/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator)
├── kube-client v0.73.0
│   ├── kube v0.73.0 (*)
│   └── kube-runtime v0.73.0
│       └── kube v0.73.0 (*)
├── kube-core v0.73.0
│   ├── kube v0.73.0 (*)
│   └── kube-client v0.73.0 (*)
└── kube-runtime v0.73.0 (*)

Looking at this output, it seems like kube-runtime is my culprit.

notjames commented 2 years ago

great pointers...I had to tweak the arguments a little for the cargo tree command...

✦ at 13:01:28 ❯ cargo tree -i k8s-openapi:0.11.0
warning: Patch `openssl v0.9.24 (https://github.com/ishitatsuyuki/rust-openssl?branch=0.9.x#3b73dda4)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
k8s-openapi v0.11.0
├── kube v0.52.0
│   └── kube-runtime v0.52.0
│       └── credrotate-k8s-operator v0.0.1 (/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator)
└── kube-runtime v0.52.0 (*)

└>jimconn on vmlinux in k8s-operators/cred-rotator/operator ・
✦ at 13:01:58 ❯ cargo tree -i k8s-openapi:0.15.0
warning: Patch `openssl v0.9.24 (https://github.com/ishitatsuyuki/rust-openssl?branch=0.9.x#3b73dda4)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
k8s-openapi v0.15.0
├── credrotate-k8s-operator v0.0.1 (/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator)
├── kube v0.73.0
│   └── credrotate-k8s-operator v0.0.1 (/home/me/projects/src/my/projects/k8s-operators/cred-rotator/operator)
├── kube-client v0.73.0
│   ├── kube v0.73.0 (*)
│   └── kube-runtime v0.73.0
│       └── kube v0.73.0 (*)
├── kube-core v0.73.0
│   ├── kube v0.73.0 (*)
│   └── kube-client v0.73.0 (*)
└── kube-runtime v0.73.0 (*)

Looking at this output, it seems like kube-runtime is my culprit.

OK, this worked:

kube          = { version = "~0.73", features = ["runtime", "derive"] }
k8s-openapi   = { version = "~0.15", features = ["v1_21"] }
kube-derive   = "~0.73"
kube-runtime  = "~0.73"

Thanks guys! This was a good lesson learner.

Arnavion commented 2 years ago

I'll tweak the error to mention the possibility of multiple versions, and to suggest the cargo tree invocation.