jenkins-x / jx

Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton
https://jenkins-x.io/
Apache License 2.0
4.58k stars 788 forks source link

jx boot against Azure AKS cluster results in: error: : unable to parse [clustername] as <project id>_<zone>_<cluster name> #6702

Closed bitsofinfo closed 3 years ago

bitsofinfo commented 4 years ago

Summary

jx boot against AKS cluster results in: error: : unable to parse [clustername] as <project id>_<zone>_<cluster name>

Steps to reproduce the behavior

Following the getting started install guide, run jx boot against an Azure AKS cluster with nothing on it.

Expected behavior

It works

Actual behavior

$ jx boot
Creating boot config with defaults, as not in an existing boot directory with a git repository.
Attempting to resolve version for boot config https://github.com/jenkins-x/jenkins-x-boot-config.git from https://github.com/jenkins-x/jenkins-x-versions.git
No Jenkins X pipeline file jenkins-x.yml or no jx boot requirements file jx-requirements.yml found. You are not running this command from inside a Jenkins X Boot git clone
To continue we will clone https://github.com/jenkins-x/jenkins-x-boot-config.git @ 1.0.78 to jenkins-x-boot-config
? Do you want to clone the Jenkins X Boot Git repository? Yes

Cloning https://github.com/jenkins-x/jenkins-x-boot-config.git @ 1.0.78 to jenkins-x-boot-config
Booting Jenkins X

STEP: validate-git command: /bin/sh -c jx step git validate in dir: /Users/dog/Documents/xyz/code/dev.azure.com/oxxt-apps/xx-apps-cicd/jenkins-x/jenkins-x-boot-config/env

Git configured for user: bitsofinfo and email bitsofinfo.g@nadaobfuscated

STEP: verify-preinstall command: /bin/sh -c jx step verify preinstall --provider-values-dir="kubeProviders" in dir: /Users/dog/Documents/xyz/code/dev.azure.com/oxxt-apps/xx-apps-cicd/jenkins-x/jenkins-x-boot-config

error: : unable to parse my-cicd-dev-1 as <project id>_<zone>_<cluster name>
error: failed to interpret pipeline file /Users/dog/Documents/xyz/code/dev.azure.com/oxxt-apps/xx-apps-cicd/jenkins-x/jenkins-x-boot-config/jenkins-x.yml: failed to run '/bin/sh -c jx step verify preinstall --provider-values-dir="kubeProviders"' command in directory '/Users/dog/Documents/xyz/code/dev.azure.com/oxxt-apps/xx-apps-cicd/jenkins-x/jenkins-x-boot-config', output: ''

Jx version

The output of jx version is:

2.0.1183

Kubernetes cluster

Azure AKS

Operating system / Environment

OSx

sheerun commented 4 years ago

Same but for kapsule of scaleway. Any workaround?

hervelemeur commented 4 years ago

By removing the project and zone parts of the cluster section I resolved it with AKS.

Could you show us your jx-requirements.yaml?

vishnujanardhanan commented 4 years ago

changing the provider to aks from gke in jx-requirements.yml fixed the issue. But new error "no azure registry subscription specified in 'jx-requirements.yml' at cluster.azure" is thrown

chrismellard commented 4 years ago

To get jx boot working for AKS you need to either specify the pre-existing registry within jx-requirements.yml i.e.

cluster:
  registry: tfjxcharmingpiglet.azurecr.io

or you need to specify a subscription in which to jx boot can create its own registry, i.e.

cluster:
   azure:
      registrySubscription: <<subscriptionGuid>>

The error you're receiving is because you have not specific a registry and when jx boot is attempting to create a registry itself you have not specified a subscription under which to create this. I'm not sure why (like all the other Azure CLI commands) we aren't defaulting subscription to the subscription az is currently logged in to. Perhaps we should open a PR to allow auto-creation of a registry under the current subscription. I'm not sure however, why this guard was put in in the first place, i.e. why we fail execution without an explicit subscription id.

jenkins-x-bot commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Provide feedback via https://jenkins-x.io/community. /lifecycle stale

jenkins-x-bot commented 4 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close. Provide feedback via https://jenkins-x.io/community. /lifecycle rotten

jenkins-x-bot commented 3 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten. Provide feedback via https://jenkins-x.io/community. /close

jenkins-x-bot commented 3 years ago

@jenkins-x-bot: Closing this issue.

In response to [this](https://github.com/jenkins-x/jx/issues/6702#issuecomment-746258196): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. >Provide feedback via https://jenkins-x.io/community. >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [jenkins-x/lighthouse](https://github.com/jenkins-x/lighthouse/issues/new?title=Command%20issue:) repository.