[Container-tools] Fwd: Landrush on Windows status

[Lalatendu Mohanty]

Forwarding to container-tools.



-------- Forwarded Message --------
Subject: 	Landrush on Windows status
Date: 	Tue, 15 Dec 2015 11:47:19 +0100
From: 	Hardy Ferentschik <hardy.ferentschik at redhat.com>
To: 	Praveen Kumar <prkumar at redhat.com>, Max Rydahl Andersen 
<manderse at redhat.com>, Lalatendu Mohanty <lmohanty at redhat.com>, Brian 
(bex) Exelbierd <bexelbie at redhat.com>, Navid Ahmed Shaikh 
<nshaikh at redhat.com>, Max Rydahl Andersen <max.andersen at redhat.com>, 
Pavel Valena <pvalena at redhat.com>, pmuir at redhat.com



Hi,

since I've spend quite some time on "Landrush on Windows" over the last couple of weeks,
I thought it is time to give an update.

As discussed many times, there are two parts to it:

#1 Ability to configure the host (Windows) to contact a secondary DNS server (aka Landrush'es DNS)
    for a configured top level domain
#2 Get the Landrush DNS server to run on Windows

Regarding #1 - Todd Mancini has given us some advice on this. Bottom line is that one would need to
configure a network loopback device with the Landrush as DNS server and associate our top level domain
with this interface.

I was able to reproduce the required steps using the various Windows GUI configurations. I was also using
devcon.exe and netsh.exe to try a programmatic approach (still needs more testing). The ultimate goal here
of course would be to execute all the require commands via Ruby and the Win32 API bindings. This is something
I have not really looked deeper into yet. The caveat here is, that the commands for the creation of a loopback
device (or at least the definition of the loopback device) has changed between versions of Windows. It is
for example different between Windows 7 and Windows 10.

The problem itself seems overall solvable, but will take quite some development effort. I would expect at least
a month.

Regarding #2 - We were under the impression that the main problem to get the Landrush DNS server to work, would
be to avoid the use of fork() within the plugin [1]. I was able to change the daemon creation part to use
ChildProcess [2] and all tests pass and I tried the updated plugin on OS X without any issue. On Windows
it starts now as well, but I am running into further issues. Landrush uses another gem to provide basic
DNS server functionality - celluloid-dns. This in turn is based on celluloid-io and something called nio4r.
It is some sort of actor based framework for Windows. Unfortunately, there seems to be an issue with this
framework on Windows [3]. I can also see the locking issues described mentioned in [3] and afaiu there it is
an open question whether celluloid is even workable on Windows at all. It's for sure not tested.
Funny enough, RubyDNS [4], the actual gem used by Landrush, used to be based on EventMachine, but they switched
to Celluloid when going from 0.8.x to 0.9.x. I guess one could try to use a RubyDNS 0.8.x release as
Landrush dependency?

Overall some roadblocks are removed, but others appeared. If we continue this path we will have to commit
quite some development effort to make it work properly. Do we want to continue with this? Who has time to
work on this? Should we focus more on the vagrant-routes approach?

Maybe we should schedule a meeting to discuss the status and a way forward? Thoughts?

--Hardy
  

[1] https://github.com/phinze/landrush/issues/16
[2] https://github.com/hferentschik/landrush/tree/childprocess
[3] https://github.com/celluloid/celluloid-io/issues/74
[4] https://github.com/ioquatix/rubydns/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151221/9c5e4bfe/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attached Message Part
Type: application/pgp-signature
Size: 497 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151221/9c5e4bfe/attachment.sig>