Kubespray: vagrant up error: 'local_volume_provisioner_base_dir' is undefined

[qcho]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Performing vagrant up is is not working because error 'local_volume_provisioner_base_dir' is undefined

As far as i could check in the documentation it should work. With some guidance i can send a PR if there is anything to fix.

Thanks in advance!

Environment:

• Cloud provider or hardware configuration:

vagrant version
Installed Version: 2.0.2
Latest Version: 2.0.2

echo $VAGRANT_DEFAULT_PROVIDER
vmware_fusion

• OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"):

cat: /etc/os-release: No such file or directory
Darwin 17.4.0 x86_64

• Version of Ansible (ansible --version):

ansible 2.4.3.0
  config file = /Users/cucho/Code/kubespray/ansible.cfg
  configured module search path = [u'/Users/cucho/Code/kubespray/library']
  ansible python module location = /usr/local/Cellar/ansible/2.4.3.0_1/libexec/lib/python2.7/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 2.7.14 (default, Mar  1 2018, 19:26:37) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]

Kubespray version (commit) (git rev-parse --short HEAD):

6975cd16

Network plugin used:

output of `cat vagrant/config.rb`
$os = "ubuntu"
$network_plugin = "canal"

Copy of your inventory file:

N/A

Command used to invoke ansible:

vagrant up

Output of ansible run:
Full: https://gist.github.com/qcho/e02281a1d240d42b55990da2c078cb25
Highlight:

/ TASK [kubernetes/preinstall : Create kubernetes \
\ directories]                                    /
 ------------------------------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Tuesday 06 March 2018  17:15:44 -0300 (0:00:00.222)       0:01:35.979 ********* 
fatal: [k8s-01]: FAILED! => {"msg": "'local_volume_provisioner_base_dir' is undefined"}
fatal: [k8s-02]: FAILED! => {"msg": "'local_volume_provisioner_base_dir' is undefined"}
fatal: [k8s-03]: FAILED! => {"msg": "'local_volume_provisioner_base_dir' is undefined"}

Anything else do we need to know:

Last released version v2.4.0 doesn't have this issue.

[derwin4o]

Hi All,
I'm experiencing the same issue but on bare-metal cluster.

Regards!

[Roland0]

Hi All,

I've got the same issue.

Output

Wednesday 07 March 2018  11:03:13 +0000 (0:00:00.118)       0:04:39.858 ******* 
fatal: [k8s-01]: FAILED! => {"msg": "'local_volume_provisioner_base_dir' is undefined"}
fatal: [k8s-02]: FAILED! => {"msg": "'local_volume_provisioner_base_dir' is undefined"}
fatal: [k8s-03]: FAILED! => {"msg": "'local_volume_provisioner_base_dir' is undefined"}

Versions:

vagrant --version
Vagrant 2.0.1

printf "$(uname -srm)\n$(cat /etc/os-release)\n"
Linux 4.9.0-6-amd64 x86_64
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

ansible --version
ansible 2.4.3.0
  config file = /home/roland/git/kubespray/ansible.cfg
  configured module search path = [u'/home/roland/git/kubespray/library']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.13 (default, Nov 24 2017, 17:33:09) [GCC 6.3.0 20170516]

git rev-parse --short HEAD
6975cd16

[Roland0]

OK this looks to be very similar to issue #2279, which has been resolved, in #2274

Edit: nope this fix has been included in the release I'm using 6975cd16

[apatrascu]

I see this happens on the master branch. If you use the v2.4.0 release, it works fine.

[Roland0]

@apatrascu I'll look at trying that.

This looks like it's been fixed: #2424 / #2427

[hswong3i]

@Roland0 I didn't try on vagrant with #2427 would you mind to give a hand for testing too?

[okgolove]

I got this error during working with AWS.

[rhino5oh]

Getting this with AWS as well

[jbroq]

Hi all,
Same problem here

Linux 3.10.0-693.17.1.el7.x86_64 x86_64
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

ansible 2.4.2.0

[DimaBogdan-phie]

you can delete line:
_- "{{ local_volume_provisioner_base_dir }}"_
from
kubespray/roles/kubernetes/preinstall/tasks/main.yml

[Roland0]

I did what @DimaBogdan-phie did and it worked.

@hswong3i I'll try in the morning (GMT)

[djfill]

I have the same issue using ansible-playbook cluster.yml with AWS...
@DimaBogdan-phie this worked for me, though is this just a work around or do you know that it is not required?
Thanks.

[jbroq]

Thanks @DimaBogdan-phie, this worked also for me.
Although I have the same question @djfill ;)

[qcho]

I think a much better workaround is to use the last released version v2.4.0 until it gets fixed.

[kevingerman]

I noticed that where I was specifying -e "local_volume_base_dir=/some/path" previously, it now works to specify -e "local_volume_provisioner_base_dir=/some/path"

Looking at commit deef47c923c44069d154efc9f174cb3f30669594, _Upgrade Local Volume Provisioner Addon to v2.0.0_ I see that many behaviors that were formerly seeded by local_volume_base_dir now rely on local_volume_provisioner_base_dir in the provisioner framework.

[rhino5oh]

@qcho I think there is a big problem here if the MASTER branch is unstable. We shouldn't have to go grab a 'release' version. We should be able to clone from master and have things work. Are you saying that the master branch should be considered unstable in kubespray?

[rsmitty]

@Roland0 is right that @hswong3i's PR should fix this up. I've kicked CI off for it, will merge this afternoon if it passes. That said, I'd like to point out that the Vagrant kubespray deployment is a community contribution and it's not tested as part of our normal CI stuff. Just something to keep in mind that errors found in vagrant usage may not be caught. Of course fixes are always welcome to help make it better though.

Regarding the master branch, it's normal process for PRs to get tested with our CI tests before merging into master. The hope is that doesn't break anything, but it's absolutely not a guarantee. When we cut releases, it's a bit more involved and we run lots of tests that we don't necessarily run normally. So yeah, releases are always going to be more stable than master branches.

[rsmitty]

PR is merged if you guys want to try it again from latest master.

[Roland0]

@rsmitty I've tried the current release on master v2.4.0-261-gf253691a several times and not seen a repeat of the problem I saw.

I'd personally consider this issue resolved, unless you want to test further.

[rsmitty]

Sounds good! Going to close this issue for now. Re-open if needed.