Windows Support

[jimbo8098]

At the moment there are some key blocks on using the plugin with Windows containers though I don't think these are very big issues. I'd love to PR support for it if you guys are okay with it? It seems to me that the bulk of the issues come from using vagrant ssh-config to get the setting which of course makes sense for Linux, however, on Windows this may not always work. My suggestion is that we have a toggle within the platform settings to use WinRM instead. This would instead use the settings output from vagrant winrm-config which should be enough to ensure a connection can be established.

Whilst it is possible to work around this issue you can effectively only have one Windows environment per scenario due to the way molecule uses the connection_options in it's schema. If we allow this to be overridden in molecule-vagrant, it bypasses this setting and therefore allows Windows environments to be used in exactly the same way as Linux which is something I'd love to see.

[apatard]

I've nothing against windows support. The main pain point i guess is imho that the winrm support should added to https://github.com/todddeluca/python-vagrant first and I'm not exactly sure of its current maintainance status :(

Once this part is done, the remaining points are adding support for winrm and to the CI.

I'm not sure how to add the connection type properly to molecule-vagrant, I don't know if other plugins have to deal with multiple connection options.

The CI part would not be that hard, as I think it would be better to run that on github action only and the easiest way to do that is running the test only on vbox. I've even code somewhere to run tests only on vbox. For the CI, one interesting case would be having two instances: one instance with ssh and one with winrm at the same time, but I've yet to find time to finish fixing multiplatform support.

[jimbo8098]

Thanks @apatard , I've added an issue there to see what their feelings are. Seems I'm the only one to ask about it. Assuming it's okay I suspect I may be able to dedicate some time to it. That said the stale PRs on that repo don't exactly fill me with confidence. While a fork would be possible, I'd prefer not to if I can. I'll keep an eye on it and check back in a few weeks.

[apatard]

we'll see if it get any reaction. I have been wondering doing a fork before adding a call to vagrant validate in the vagrant module because python vagrant is supposed to handle that. I didn't create one since a fork should always be last solution imho.

If nothing happens, I'll try to reach by mail the author of python-vagrant and I'll think about doing a fork, but, again, I would hate to have to create a fork

[apatard]

Is there any news on the python-vagrant side ?

[jimbo8098]

Nah nothing on my end dude 🤷

[jimbo8098]

My work are dragging their heels on approving me working to fix this issue but I'm hoping that I'm able to do so. It will have major pros for us and I'm sure many other people using the Windows platform.

[konstruktoid]

Feel free to ignore if way off-topic, but do you know any python vagrant bindings that could be used instead?

https://github.com/todddeluca/python-vagrant was last active ~4 ago and the requirements state "Python 2.7 (the only version this package has been tested with.) or Python 3.3 or higher".

[apatard]

@konstruktoid no, I'm not aware of other bindings but my search skills are bad. Switching to something else would be a long term goal imho. molecule-vagrant is mostly working nicely (if you don't count the bugs I'm adding) and switching would lead to some turbulence.

At worse, as said previously, one possibility is to create a fork and send a PR to python-vagrant for every change but the problem would be how to make people use this fork and not the one available inside the distros. We're possibly now off-typic for this bug. Probably a new bug has to be opened for that.

[jimbo8098]

RE version-locking to that PR maybe we could pip freeze and make a requirements yaml? Alternatively I see no issue with us hosting a fork of that repo assuming the licence permits it alongside a PR. That way we would have some way of managing it. I am somewhat surprised such a thing hasn't really had much traction in such a long time. I see a PR on there since 2016 which had a comment placed on it a year later by the project owner.

Perhaps it would be more fruitful to get in touch with the owner and see if he'd be willing to add some more maintainers? Maybe it's the old problem of changing roles and not having the time/drive to maintain. I'm sure we've all been there...

[jimbo8098]

I've still had no update on my request in the repo so I think I will look to fork and look at it in my own time. If not for this particular issue, for my own benefit. Gains in the gym be damned!

[konstruktoid]

I was thinking the same, python3-vagrant?, but is a updated fork The Correct Way(tm) of doing it?

[konstruktoid]

I was thinking the same, python3-vagrant?, but is a updated fork The Correct Way(tm) of doing it?

Will start working on https://github.com/konstruktoid/python3-vagrant but we'll see how it progresses.

[konstruktoid]

Maybe a Necro warning, but https://github.com/konstruktoid/python3-vagrant is now up-to-date and all tests pass.

[konstruktoid]

winrm command and winrm-config has been added to https://github.com/konstruktoid/python3-vagrant