> 1) Did I miss it or is there no actual end-user documentation on how to use > this?
Yes, we are in the process of finishing up the the doc and posting it. We considered this a release blocker for 3.0.0-beta1 and so working on it in parallel while the branch merge happens. > 2) Lots of markdown problems in the NativeServicesDiscovery.md > document. This includes things like ‘yarnsite.xml’ (missing a dash.) Also, > I’m also confused why it’s called that when the title is YARN DNS, but > whatever. Thanks for pointing out. We will fix this. > Based on the documentation, this doesn’t appear to be a fully function DNS > server as an admin would expect (e.g., BIND, Knot, whatever). Where’s > forwarding? How do I setup notify? Are secondaries even supported? etc, etc. It seems like this is a rehash of some of the discussion you and others had on the JIRA. The DNS here is a thin layer backed by service registry. My understanding from the JIRA is that there are no claims that this is already a DNS with all the bells and whistles - its goal is mainly to expose dynamic services running on YARN as end-points. Clearly, this is an optional daemon, if the provided feature set is deemed insufficient, an alternative solution can be plugged in by specific admins because the DNS piece is completely decoupled from the rest of native-services. > In fact: was this even tested on port 53? How does this get launched such > that it even has access to open port 53? I don’t see any calls to use the > secure daemon code in the shell scripts. Is there any jsvc voodoo or is it > just “run X as root”? Yes, we have tested this DNS server on port 53 on a cluster by running the DNS server as root user. The port is clearly configurable, so the admin has two options. Run as root + port 53. Run as non-root + non-privileged port. We tested and left it as port 53 to keep it on a standard DNS port. It is already documented as such though I can see that part can be improved a little. > 4) Post-merge, yarn usage information is broken. This is especially > bad since it doesn’t appear that YarnCommands was ever updated to include the > new sub-commands. The “yarn” usage command is working for me. what do you mean ? Yeah, looks like some previous features also forgot to update YarnCommands.md for the new sub commands
