Provided SSH keypair not used for bootstrap node about hive

[2uasimojo]

ClusterDeployment.Spec.Provisioning.SSHPrivateKeySecretRef is a LocalObjectReference -- we expect to find the secret in the same namespace as the ClusterDeployment. So...

$ kubectl create secret generic "ssh-key"
--namespace hive
--from-file ssh-privatekey=ssh-key
--from-file ssh-publickey=ssh-key.pub

Is your ClusterDeployment also in namespace hive?

Now, arguably we should somehow fail if you specify that secret and we can't find it...

[Nashluffy]

Yes, the cluster deployment lives in the same namespace. When I was pulling the key pair that terraform created from inside the provision pod, I saw my own key pair present under /sshkeys/

[2uasimojo]

@patrickdillon can you please advise here? It sounds like hive is correctly laying down the SSH keys under /sshkeys -- does installer know to look there (assuming its wd is /)? Do we expect to be able to use those keys for the bootstrap node?

[openshift-bot]

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

[Nashluffy]

/remove-lifecycle stale

[2uasimojo]

@patrickdillon bump

[openshift-bot]

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

[patrickdillon]

/remove-lifecycle stale

[patrickdillon]

The ssh key needs to be included in the install config: installconfig.sshKey. If one isn't provided, the installer may create one. That could be a possible explanation for this behavior.