openshift / hive

API driven OpenShift cluster provisioning and management
Apache License 2.0
247 stars 238 forks source link

adoption requires cloud credentials #774

Closed mhrivnak closed 3 years ago

mhrivnak commented 4 years ago

I ran make build and make deploy from the v1 branch. I then tried to "adopt" an existing cluster and got an error message about missing AWS credentials. Cloud credentials should not be required for adoption. I saw a similar message if I specified the cloud as "azure" or "gcp".

$ bin/hiveutil create-cluster --adopt --adopt-admin-kubeconfig=/tmp/cluster0.config --adopt-cluster-id=cluster0 --adopt-infra-id=cluster0 cluster0
ERRO[0000] Cannot load AWS credentials                  
ERRO[0000] Error                                         error="open /home/mhrivnak/.aws/credentials: no such file or directory"
mhrivnak commented 4 years ago

I added --include-secrets=false to the command and that enabled it to succeed. That causes the create command to skip this block of code, which tries to get the cloud credentials by calling o.cloudProvider.generateCredentialsSecret(o)

staebler commented 4 years ago

Cloud credentials are required for Hive to manage a cluster. The credentials are not used solely during provisioning: The credentials are used for on-going operations and for de-provisioning as well.

mhrivnak commented 4 years ago

The docs describe adopting a "kind" cluster for dev purposes, which presumably cannot take advantage of any cloud credentials. Seems like there should be a way to do that without being required to provide credentials.

https://github.com/openshift/hive/blob/v1/docs/developing.md#adopting-clusterdeployments

staebler commented 4 years ago

The docs describe adopting a "kind" cluster for dev purposes, which presumably cannot take advantage of any cloud credentials.

Yes, however, even when adopting a "kind" cluster, the aws creds are required. In the example provided, the "kind" cluster is adopted as an AWS cluster.

dhellmann commented 4 years ago

There won't be any cloud credentials for a bare metal cluster. How do we plan to deal with that?

mhrivnak commented 4 years ago

The docs describe adopting a "kind" cluster for dev purposes, which presumably cannot take advantage of any cloud credentials.

Yes, however, even when adopting a "kind" cluster, the aws creds are required. In the example provided, the "kind" cluster is adopted as an AWS cluster.

I may be misunderstanding, but it looks in the example like both the hive cluster and the new managed cluster (cluster1) are running in kind on a developer's local machine. When you say it is adopted "as an AWS cluster", what does that mean? How would AWS credentials be used in managing it?

staebler commented 4 years ago

There won't be any cloud credentials for a bare metal cluster. How do we plan to deal with that?

The hiveutil command does not yet support bare metal clusters. It does not support creating or adopting bare metal clusters. When the hiveutil command does support bare metal, then it will not ask for any credentials because, as you stated, bare metal does not use credentials.

staebler commented 4 years ago

The docs describe adopting a "kind" cluster for dev purposes, which presumably cannot take advantage of any cloud credentials.

Yes, however, even when adopting a "kind" cluster, the aws creds are required. In the example provided, the "kind" cluster is adopted as an AWS cluster.

I may be misunderstanding, but it looks in the example like both the hive cluster and the new managed cluster (cluster1) are running in kind on a developer's local machine. When you say it is adopted "as an AWS cluster", what does that mean? How would AWS credentials be used in managing it?

The hiveutil command has a --cloud flag that defaults to AWS. The ClusterDeployment created by the hiveutil example has a platform of AWS.

staebler commented 4 years ago

Note that you are not required to use the hiveutil command. If you would like to adopt a cluster that you would like Hive to treat as a bare metal cluster, then you are free to create the ClusterDeployment and associated resources manually rather than having the hiveutil command create them for you.

djzager commented 4 years ago

While this flag (--include-secrets=false) is still present on master, it is useless for the purpose of cluster adoption.

Note that you are not required to use the hiveutil command. If you would like to adopt a cluster that you would like Hive to treat as a bare metal cluster, then you are free to create the ClusterDeployment and associated resources manually rather than having the hiveutil command create them for you.

I would have happily pursued this route, instead of reverting back to a sufficiently old version of hive that would work, if I could find something in the documentation about adopting a cluster that didn't use hiveutil. Not certain this note about adopting ClusterDeployments would work against master based on my experience with a minikube cluster.

openshift-bot commented 3 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented 3 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

openshift-bot commented 3 years ago

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift-ci-robot commented 3 years ago

@openshift-bot: Closing this issue.

In response to [this](https://github.com/openshift/hive/issues/774#issuecomment-745043176): >Rotten issues close after 30d of inactivity. > >Reopen the issue by commenting `/reopen`. >Mark the issue as fresh by commenting `/remove-lifecycle rotten`. >Exclude this issue from closing again by commenting `/lifecycle frozen`. > >/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 [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.