Multiple datastores requested during "juju bootstrap"

juju
1

Hi,

Im trying to do a vsphere deployment. I have 3 nodes, two of them having two datastores and the third one has only one.
It appears to me that juju deploys on the node where the vCenter appliance is deployed. This node has two datastores (well, 3 but 1 is not usable). If I dont provide data store during bootstrap it stops requiring to provide a datastore and listing the available ones. After I provide it with:

juju bootstrap --config datastore=“datastore-name” cloud-name

it starts:

Creating Juju controller “cloud-name-datacentername” on cloud-name/datacentername
Looking for packaged Juju agent version 2.8.0 for amd64
WARNING empty string passed as vm-folder, using Datacenter root folder instead
Launching controller instance(s) on cloud-name/datacentername…
WARNING empty string passed as vm-folder, using Datacenter root folder instead
WARNING empty string passed as vm-folder, using Datacenter root folder insteadd90e7cee1ebaa0bd85f127272"

And it stops sayng that the provided “datastore-name” does not exist (it does) and shows as a available another valid datastore but on a different ESXi node.

So my question is is it trying to do deployment on multiple nodes and if yes how can I provide multiple datastores for the various nodes?

Thank you

2

The error is because Juju is trying to use the specified datastore (which will be the default one for the model) as the root disk data store for the VM it is creating. Maybe that datastore is in a different resource group / availability zone and is not accessible to the VM Juju is trying to provision for bootstrap.

There’s 2 options you can try to use to tweak things.

  1. Specify the root-disk-source and that datastore will be used in preference to the default
    eg

juju bootstrap vsphere --constraints=“root-disk-source=another-datastore” …

  1. Specify the availability zone in which the bootstrapped VM should be provisioned to ensure the default datastore is accessible
    eg

juju bootstrap vsphere --to zone=someavailabilityzone …

You could also use --debug to see some additional relevant info which may help.

Hopefully that helps. I am not a vsphere expert so can’t guarantee what I suggested will work straight up.

1 Like
3

Hi,
Using --debug it turned out that there is a firewall issue and juju also attempts to access the individual ESXi hosts (not just vCenter) and this was causing it to bounce from host to host trying to deploy (and on the next host the provided datastore name is no longer valid).
I got through the deployment but when Im trying to obtain the config file with:

$ juju scp kubernetes-master/0:config ~/.kube/config

fails as I dont have the ssh keys. I cant do juju ssh to the machine due to the same reason… And in the install guide there is no word how to obtain these. I see the machines running in vSphere but I cant access them at all.

The other issue is that with “watch -c juju status --color” I can see there are failed machines again due to “no datastore provided and multiple available” but I will figure how to provide this… I just havent looked into this.
Thank you!

4

as I dont have the ssh keys. I cant do juju ssh to the machine due to the same reason… And in the install guide there is no word how to obtain these.

Juju SSH keys supposed to live in .local/share/juju/ssh/ folder on the Juju machine. But as you say, you cannot login via juju ssh command, then something is wrong with SSH keys.

5

Yes, it is a chicken and egg situation. I expected to be able to login directly to the machine after the installation (to have keys exchanged during this process). Anyway, for now Im using Swarm.