johnomernik/maprdcos

Running MapR on DCOS

maprdcos's Issues

Allow user to specify MapR license key?

More of an idea than an issue, but it would be nice to be able to specify a license key and/or specify MapR credentials to have the cluster spin up licensed out of the box.

Fuse Client on Phys Node with NFS Server in Dockerized Server issue

If you are running the posix client (FUSE) on a physical node, and the docker container (MapR Server) is running the NFS server. The Fuse Client will fail randomly. It provides little error, just umounts and has to be restarted.

MapR FUSE Client Doesn't work on Physical Nodes

Due to a currently being investigated bug, the MapR FUSE client doesn't work. However, if you wish to install the FUSE client, the Hadoop client will work on every node at this point. Just the fuse Filesystem will not work.

Alternative: start NFS on a node, and mount /mapr from all agents to that NFS server.

a

Mount NFS in MapR Client Docker Image

Not an issue, but an idea, I think we should mount up the cluster via NFS in the MapR Client build. Shouldn't be hard to do, but I think the "right" way to do it is to add the loopback or fuse client script to the image and run it, instead of hard coding in the image build script. Thoughts?

Create docker containers for running scripts - Including container builds

To increase compatibility, create docker containers to run the various scripts in this repo, including the scripts that build the containers (Docker in Docker). This is to help increase cross platform compatibility. The idea here is the ability to run this on any base OS running DC/OS.

The one challenge here will be the scripts that operate directly on the OS. I.e. the MapR packages for FUSE or NFS Loop back. Some OSes may not be able to run these on the host OS.

Alternatives would be to used licensed MapR and use the native NFS client.

mapr user needs MapR-FS directory

Should create the /user/mapr directory in MapR-FS, otherwise certain features of the MapR Control System (when logged in as the MapR user) don't work, specifically MapR Tables.

Discuss Secure Method for Handling Credentials

Because the credentials used in the user prep script have to saved for use in the docker containers (or do they?) We store them in a directory in /home/zetaadm/creds We lock this directory down, but it's still scary to have credentials there.

Some points:

• Should we clean up at some point?
• Should we encrypt them and use a key?
• Where would we keep that key?
  • Perhaps and RSA key that required a passphrase to be entered every time the credentials are used?
• Other options?

MapR Node install script requires bc to be installed

We should rewrite the memory calculations to occur within a docker container so bc and other tools don't need to be installed on the node you are doing the install from.

MapR Loopback NFS Does not work

Due to an issue with shared memory, the NFS Loopback doesn't work at this time. Currently working with MapR.

Alternatives: If using M3 (community) MapR, start NFS on a node, and have all individual nodes mount NFS there.

Clearly document community vs. enterprise MapR differences

The build scripts obviously work for both the community and enterprise MapR versions, however it's easy for a community user to do things that the community edition doesn't support (multiple CLDBs, multiple NFS nodes, etc.). We should clearly document areas/decisions that are impacted and perhaps have a question that asks which version is being installed and change the questions accordingly.