When creating new LXC container with help of salt-cloud lxc.init crashes
with similar message:
[INFO ] Creating container(s) '['test-host']' on host 'lxc-host'
[ERROR ] Failed to create VM test-host. Configuration value 'test-host' needs to be set
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/cloud/__init__.py", line 1193, in create
output = self.clouds[func](vm_)
File "/usr/lib/python2.7/dist-packages/salt/cloud/clouds/lxc.py", line 424, in create
cret = _runner().cmd('lxc.cloud_init', [vm_['name']], kwarg=kwarg)
File "/usr/lib/python2.7/dist-packages/salt/runner.py", line 123, in cmd
return self.functions[fun](*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/salt/runners/lxc.py", line 355, in cloud_init
saltcloud_mode=True, quiet=quiet, **kwargs)
File "/usr/lib/python2.7/dist-packages/salt/runners/lxc.py", line 257, in init
kw['seed'] = seeds[name]
KeyError: 'test-host'
The reason is that salt-cloud always passes generated keys to lxc.init,
it skips seeds dictionary population and errors out trying to lookup
non-existent key.
Fix this by using fallback value of True because we always want to seed
minion in such case.
Taking the minion config from the master system is dangerous, because
there may be an actual minion on the system and if we're not careful we
may override options we don't want to, resulting in hard-to-track-down
errors. Instead, allow for explicit minion config defined in the master.
Upon testing (in my Windows environment), I noticed that in
clean_proc_dir():
job = salt.payload.Serial(opts).load(fp_)
The result would always be that 'job' is None. Upon further
investigation, this seems to be the case because of this line above:
job_data = fp_.read()
If I remove that line, things work as expected. So it seems like the
'fp_.read()' will move the current file position of 'fp_' to the end,
and so 'salt.payload.Serial(opts).load(fp_)' would end up reading what
it thinks is an empty file.
Looking at the logic, it seems like 'job_data = fp_.read()' is an
unnecessary step in any case, so it has been removed.
I have noticed that this same incorrect logic also exists in the 2015.2
and 2014.7 branches.
Also, added a fix for deleting files on Windows which was already in
another part of the same function.
Signed-off-by: Sergey Kizunov <sergey.kizunov@ni.com>
