Follow log directory creation pattern from other providers

[miha-plesko]

With this commit we further improve log directory creation now that it's missing from git. This approach is better than what we had before because

a) it uses absolute path and will work regardless $PWD
b) it's executed everytime bin/setup is run, not just upon
spec/manageiq link creation

Copied from: ManageIQ/manageiq-providers-kubernetes#273

/cc @cben @tadeboro

[miq-bot]

Checked commit miha-plesko@1263801 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
0 files checked, 0 offenses detected
Everything looks fine. 👍

[tadeboro]

I feel that this solution does not solve anything. If spec/manageiq folder already exists, it means that bin/setup already cloned it and ensured that log folder is present (this is what current solution does).

If developer manages spec/manageiq contents manually, then I would argue that creating a log folder automatically makes little sense (and may even annoy grumpy developers like me ;).

And about that relative/absolute path: git clone is already done using relative path, so no harm in using relative path there.

[miha-plesko]

I must disagree, action "create empty log directory unless exist" is reasonable thing to do in bin/setup script. If one find it annoying that it automatically creates things for you, then he shouldn't call it in first place :P

[tadeboro]

I have a problem that latest solution can create it on the other side of the file system in case of symlinked spec/manageiq. I really do not want something from /a/b/c/d messing around with /a/b/e/f.

[cben]

good point (though bin/setup under a provider causes stuff to be written to files under spec/manageiq/log/ anyway).
I don't really care which way we do it, waiting for gitter discussion to settle...

[tadeboro]

The stuff that is placed in into spec/manageiq/log folder is created by code in the core repo. But yeah, I am also sitting with a popcorn on my lap and waiting for things to settle down;)

[miha-plesko]

Closing as issue has been resolved in core repo via ManageIQ/manageiq#17886 so providers no longer need to bother with it.