Closed nbr closed 7 years ago
This looks reasonable, thanks. I'm curious what the use case is though? From my perspective it seems like if you don't want the DNS or UNFS enabled you'd be better off just using Docker for Mac, so I must be missing a use case.
Also, are you using something else in place of UNFS where the fsevents forwarder still makes sense to run? It was designed pretty specifically around how the UNFS sharing works, so I'm not sure it makes sense to run fsevents if unfs is disabled, but maybe it works well enough with some other fs sharing solution?
This looks reasonable, thanks. I'm curious what the use case is though? From my perspective it seems like if you don't want the DNS or UNFS enabled you'd be better off just using Docker for Mac, so I must be missing a use case.
Also, are you using something else in place of UNFS where the fsevents forwarder still makes sense to run? It was designed pretty specifically around how the UNFS sharing works, so I'm not sure it makes sense to run fsevents if unfs is disabled, but maybe it works well enough with some other fs sharing solution?
For DNS, the use case is to use https://github.com/FreedomBen/dory instead, which has built-in integration with dinghy and will also work on Linux and Docker for Mac.
For UNFS, the intention is to make it possible to use other FS sharing solutions, which may or may not have better performance than UNFS. It is currently not possible to experiment.
As far as I can tell, fsevents_to_vm
is still useful for other NFS solutions, e.g. using macOS nfsd as the server.
Regarding Docker for Mac, for my application the performance of NFS is still superior to their volume mounting solution, and I have found dinghy to be the most stable option for using NFS and Docker.
Cool, sounds reasonable. If you do experiment with using the OS built-in NFS server, be careful of the security implications, since it doesn't listen on just the virtual networking interface like dinghy's unfs3 solution does. Thanks for the PR.
Add
:dns_disabled
Disable DNS/HTTP proxy altogether by setting
:dns_disabled: true
in~/.dinghy/preferences.yml
, or by passing--no-dns
flag on CLI. Note that disabling DNS will force HTTP proxy to be disabled.Add
:unfs_disabled
See https://github.com/codekitchen/dinghy/pull/232
Display services as
disabled
This helps to differentiate crashed services from disabled services. Uses contributions from https://github.com/codekitchen/dinghy/pull/232.
Example:
Fix
fsevents_disabled
reset issueWhen
:fsevents_disabled: true
in~/.dinghy/preferences.yml
, after runningdinghy create
ordinghy up
, that value will be reset tofalse
.Preferences#update
was being passed{fsevents_disabled: !fsevents, ... }
, wherefsevents
returns aFseventsToVm
object (thus it is trivially truthy).