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.

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

stackablectl: Retry GVK resolution #293

Closed
Tracked by #148
sbernauer opened this issue May 27, 2024 · 1 comment · Fixed by #294
Closed
Tracked by #148

stackablectl: Retry GVK resolution #293

sbernauer opened this issue May 27, 2024 · 1 comment · Fixed by #294
Labels

Comments

@sbernauer
Copy link
Member

sbernauer commented May 27, 2024

Affected version

main

Current and expected behavior

When installing a stack that install a new CRD and afterwards tries to create an object of that new kind (such as stackabletech/demos#35) we fail with the following error message

  DEBUG  Installing YAML manifest from stacks/observability/opentelemetry-collector-sidecar.yaml
    at src/platform/manifests.rs:125
    in install_manifests
    in prepare_manifests
    in install with install_parameters: StackInstallParameters { demo_name: None, stack_name: "observability", operator_namespace: "stackable-operators", product_namespace: "default", parameters: [], skip_release: false, labels: Labels(KeyValuePairs({KeyValuePair { key: Key { prefix: Some(KeyPrefix("stackable.tech")), name: KeyName("managed-by") }, value: LabelValue("stackablectl") }, KeyValuePair { key: Key { prefix: Some(KeyPrefix("stackable.tech")), name: KeyName("stack") }, value: LabelValue("observability") }, KeyValuePair { key: Key { prefix: Some(KeyPrefix("stackable.tech")), name: KeyName("vendor") }, value: LabelValue("Stackable") }})) }
    in install_cmd with args: StackInstallArgs { stack_name: "observability", skip_release: false, stack_parameters: [], parameters: [], local_cluster: CommonClusterArgs { cluster_type: None, cluster_name: "stackable-data-platform", cluster_nodes: 2, cluster_cp_nodes: 1 }, namespaces: CommonNamespaceArgs { operator_namespace: "stackable-operators", product_namespace: "default" } }
    in run with self: Cli { log_level: Some(Level(Debug)), no_cache: false, offline: false, files: CommonFileArgs { demo_files: [], stack_files: ["stacks/stacks-v2.yaml"], release_files: [] }, repos: CommonRepoArgs { helm_repo_stable: "https://repo.stackable.tech/repository/helm-stable/", helm_repo_test: "https://repo.stackable.tech/repository/helm-test/", helm_repo_dev: "https://repo.stackable.tech/repository/helm-dev/" }, subcommand: Stack(StackArgs { subcommand: Install(StackInstallArgs { stack_name: "observability", skip_release: false, stack_parameters: [], parameters: [], local_cluster: CommonClusterArgs { cluster_type: None, cluster_name: "stackable-data-platform", cluster_nodes: 2, cluster_cp_nodes: 1 }, namespaces: CommonNamespaceArgs { operator_namespace: "stackable-operators", product_namespace: "default" } }) }) }

An unrecoverable error occured: failed to execute stack (sub)command

Caused by these errors (recent errors listed first):
 1: failed to install stack "observability"
 2: failed to install stack manifests
 3: failed to deploy manifests using the kube client
 4: failed to deploy manifest because GVK GroupVersionKind { group

This is proably because we cache GVK here

let discovery = Discovery::new(client.clone())
.run()
.await
.context(KubeClientFetchSnafu)?;

Possible solution

Once we run into an GVK error we should run Discovery::run and give it another try.

However I'm 100% confident, this needs to be tested

Additional context

No response

Environment

No response

Would you like to work on fixing this bug?

None

@NickLarsenNZ
Copy link
Member

Related: We need to find out why the who error isn't being printed in the Snafu report.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants