Known Issues and Limitations in Cloudera Data Science Workbench 1.8.1

• If CDSW is using HTTP or HTTPS_PROXY settings the following will occur:
  • The _Terminal will spin forever.
  • The applications will not reach a started state.
  You can access the _Terminal by going to: tty- {engine id} .cdsw-url.com. There is no workaround.

  Cloudera Bug: DSE-12898

• The CDSW terminal remains active even after the CDSW web session times out.

  Cloudera Bug: DSE-12064

• The CDSW web UI might freeze while updating the job schedule to Dependant if there is no other job to be depended on.

  Workaround: If there are no jobs to be dependent on, then refresh the page and select the appropriate setting from the Schedule field before saving other changes on the page.

  Cloudera Bug: DSE-12032

• Restarting an application from Cloudera Manager crashes the kubelet process on a kernel older than 4.3 and CDSW 1.8 running on the Kubernetes cluster 1.14.x because of an existing Kubernetes bug. This happens because the kernel version does not support cgroups pids controller.

  Workaround: Install CDSW 1.8 on nodes that have the kernels having cgroups for pids feature enabled. To check whether the kernel has the pids feature enabled, run the following command:

  cat /proc/cgroups/

  If the subsystem (subsys_name) in the output does not contain pids, then do not install CDSW 1.8 on that node.

  Sample output showing subsystem does not list pids:

  subsys_name
  hierarchy
  num_cgroups
  enabled
  cpuset
  8
  17
  1
  cpu
  9
  17
  1
  cpuacct
  9
  17
  1
  memory
  10
  17
  1
  devices
  2
  30
  1
  freezer
  6
  17
  1
  net_cls
  3
  17
  1
  blkio
  4
  17
  1
  perf_event
  5
  17
  1
  hugetlb
  7
  17
  1

  Sample output showing subsystem that lists pids:

  #subsys_name
  hierarchy
  num_cgroups
  enabled
  cpuset
  5
  91
  1
  cpu
  9
  91
  1
  cpuacct
  9
  91
  1
  memory
  2
  91
  1
  devices
  8
  91
  1
  freezer
  7
  91
  1
  net_cls
  3
  91
  1
  blkio
  10
  91
  1
  perf_event
  4
  91
  1
  hugetlb
  11
  91
  1
  pids
  6
  91
  1
  net_prio
  3
  91
  1

  Cloudera Bug: DSE-11750

• Third-party security and orchestration software (such as McAfee, Tanium, Symantec) can lead to CDSW crashing randomly

  Workaround: Disable all third-party security agents on CDSW hosts.

  Cloudera Bug: DSE-8550

• High I/O utilization on the application block device can cause the application to stall or become unresponsive. Users should read and write data directly from HDFS rather than staging it in their project directories.

• Installing ipywidgets or a Jupyter notebook into a project can cause Python engines to hang due to an unexpected configuration. The issue can be resolved by deleting the installed libraries from the R engine terminal.

• You cannot disable file upload and download when using the Jupyter Notebook.

  Cloudera Bug: DSE-12065

• You may see the following message if you try to open a file in CDSW that contains Chinese characters in the filename: An error occurred while trying to open the file /filepath/filename.py.info. The file could not be found..

  Workaround: From the CDSW UI, click the file that you are trying to open and then click Open in Workbench.

  Cloudera Bug: DSE-11891

• Logs generated by a browser IDE do not appear within the IDE. They are displayed in the Logs tab for the session.

  Cloudera Bug: DSE-6570

• Sessions with Browser IDEs running do not adhere to the limit set in IDLE_MAXIMUM_MINUTES. Session logs show the warning message that states that the idle session will timeout, but the timeout does not occur. The session continues to run and consume resources until the timeout set in SESSION_MAXIMUM_MINUTES is reached. Ensure that you manually stop a session after you are finished, so that the resources are available to other users.

  Cloudera Bug: DSE-6651

• Sessions with Browser IDEs running time out with no warning after the time limit set in SESSION_MAXIMUM_MINUTES is reached, regardless of whether or not the session is idle. Periodically stop the browser IDE and session manually to avoid reaching SESSION_MAXIMUM_MINUTES.

  Cloudera Bug: DSE-6652

• The lack of a ROOT CA certificate can cause issues with terminals and the Jupyter editor after upgrading CDSW.

  Problem: After upgrading from CDSW version 1.5 to version 1.7.1, the terminal does not open for any kernel, and the Jupyter notebook does not work.

  Workaround: In CDSW, go to Admin > Security, and paste the internal CA root certificate file contents directly into the Root CA configuration field. You should be able to launch a new session and start the terminal or launch the Jupyter editor. It is not necessary to restart CDSW. This procedure is described at Configuring Custom Root CA Certificate

• The CDSW web UI does not display any acknowledgment message when you update the shared memory and save the change.

  Cloudera Bug: DSE-12034

• When you create a job with a non-default engine profile, the job overview page displays the Engine Profile value as 1 vCPU / 2 GiB Memory instead of the actual engine profile that was selected while creating a CDSW project.

  Cloudera Bug: DSE-12033

• The output of the terminal commands including the curl command may wrap incorrectly, resulting in a terminal output that is difficult to read.

  Workaround: Resize the terminal to a bigger size.

  Cloudera Bug: DSE-11956

• Configuring duplicate mount points in the site admin panel (Admin > Engines > Mounts) results in sessions crashing in the workbench.

  Cloudera Bug: DSE-3308

• Spawning remote workers fails in R when the env parameter is not set. For more details, see Distributed Computing with Workers.

  Cloudera Bug: DSE-3384

• Autofs mounts are not supported with Cloudera Data Science Workbench.

  Cloudera Bug: DSE-2238

• When using Conda to install Python packages, you must specify the Python version to match the Python versions shipped in the engine image (2.7.11 and 3.6.1). If not specified, the conda-installed Python version will not be used within a project. Pip (pip and pip3) does not face this issue.

• When engine version 8 (or higher) is used, and the Allow containers to run as root property is disabled, the creation of containers that run with root privileges is prevented. Additionally, the elevation of privileges from the cdsw user to root (for example, using a setuid binary) is also prevented.

  As a result, running the ping command, which is actually a setuid binary, will fail in engine 8 (or higher) when Allow containers to run as root property is disabled.

  $ ping www.google.com
  Ping: icmp open socket: Operation not permitted.

• Experiments do not store snapshots of project files. You cannot automatically restore code that was run as part of an experiment.

• Experiments will fail if your project filesystem is too large for the Git snapshot process. As a general rule, any project files (code, generated model artifacts, dependencies, etc.) larger than 50 MB must be part of your project's .gitignore file so that they are not included in snapshots for experiment builds.

• Experiments cannot be deleted. As a result, be conscious of how you use the track_metrics and track_file functions.

  • Do not track files larger than 50MB.
  • Do not track more than 100 metrics per experiment. Excessive metric calls from an experiment may cause Cloudera Data Science Workbench to hang.

• The Experiments table will allow you to display only three metrics at a time. You can select which metrics are displayed from the metrics dropdown. If you are tracking a large number of metrics (100 or more), you might notice some performance lag in the UI.

• Arguments are not supported with Scala experiments.

• The track_metrics and track_file functions are not supported with Scala experiments.

• The UI does not display a confirmation when you start an experiment or any alerts when experiments fail.

• When you start a job that has a dependent job, CDSW does not log the job start event for the dependent job in the user_events table.

  Cloudera Bug: DSE-11855

• Cloudera Data Science Workbench does not support changing your API key, or having multiple API keys.

• Currently, you cannot use the Jobs API to create a job, stop a job, or get the status of a job.

• Known Issues with Model Builds and Deployed Models

  • (If quotas are enabled) Models that are stuck in the Scheduled state due to lack of resources do not automatically start even if you free up existing resources.

    Workaround: Stop the Model that is stuck in the Scheduled state. Then manually reschedule that Model.

    Cloudera Bug: DSE-6886

  • Unable to create a model with the name of a deleted Model.

    Workaround: For now, Models shall have unique names across the lifespan of the cluster installation.

    Cloudera Bug: DSE-4237

  • Re-deploying or re-building models results in model downtime (usually brief).

  • Model deployment will fail if your project filesystem is too large for the Git snapshot process. As a general rule, any project files (code, generated model artifacts, dependencies, etc.) larger than 50 MB must be part of your project's .gitignore file so that they are not included in snapshots for model builds.

  • Model builds will fail if your project filesystem includes a .git directory (likely hidden or nested). Typical build stage errors include:

    Error: 2 UNKNOWN: Unable to schedule build: [Unable to create a checkpoint of current source: [Unable to push sources to git server: ...

    To work around this, rename the .git directory (for example, NO.git) and re-build the model.

    Cloudera Bug: DSE-4657

  • JSON requests made to active models should not be more than 5 MB in size. This is because JSON is not suitable for very large requests and has high overhead for binary objects such as images or video. Call the model with a reference to the image or video, such as a URL, instead of the object itself.

  • Any external connections, for example, a database connection or a Spark context, must be managed by the model's code. Models that require such connections are responsible for their own setup, teardown, and refresh.

  • Model logs and statistics are only preserved so long as the individual replica is active. Cloudera Data Science Workbench may restart a replica at any time it is deemed necessary (such as bad input to the model).

• The use_model_metrics.py file which is available within the CDSW Templates misses the code for setting the user_api_key and is not up-to-date. Use the following code instead:

  import cdsw
  import time
  from sklearn import datasets
  import numpy as np
  
  # This script demonstrates the usage of several model metrics-
  # related functions:
  # - call_model: Calls a model deployed on CDSW as an HTTP endpoint.
  # - read_metrics: Reads metrics tracked for all model predictions
  #   made within a time window. This is useful for  doing analytics 
  #   on the tracked metrics.
  # - track_delayed_metrics: Adds metrics for a given prediction 
  #   retrospectively, after the prediction has already been made.
  #   Common examples of such metrics are ground truth and various
  #   per-prediction accuracy metrics.
  # - track_aggregate_metrics: Adds metrics for a set or batch of
  #   predictions within a given time window, not an individual 
  #   prediction. Common examples of such metrics are mean or 
  #   median accuracy, and various measures of drift.
  
  # This script can be used in a local development mode, or in
  # deployment mode. To use it in deployment mode, please: 
  # - Set dev = False
  # - Create a model deployment from the function 'predict' in
  #   predict_with_metrics.py 
  # - Obtain the model deployment's CRN from the model's overview
  #   page and the model's access key from its settings page and 
  #   paste them below.
  # - If you selected "Enable Authentication" when creating the
  #   model, then create a model API key from your user settings 
  #   page and paste it below as well.
  
  dev = True
  
  # Conditionally import the predict function only if we are in
  # dev mode
  try:
      if dev:
          raise RuntimeError("In dev mode")
  except:
      from predict_with_metrics import predict
  
  if dev:
      model_deployment_crn=cdsw.dev_model_deployment_crn # update modelDeploymentCrn
      model_access_key=None
  else: 
      # The model deployment CRN can be obtained from the model overview
      # page.
      model_deployment_crn=None 
      if model_deployment_crn is None:
          raise ValueError("Please set a valid model deployment Crn")
  
      # The model access key can be obtained from the model settings page.
      model_access_key=None
      if model_access_key is None:
          raise ValueError("Please set the model's access key")
  
      # You can create a models API key from your user settings page.
      # Not required if you did not select "Enable Authentication"
      # when deploying the model. In that case, anyone with the
      # model's access key can call the model.
      user_api_key = None
  
  # First, we use the call_model function to make predictions for 
  # the held-out portion of the dataset in order to populate the 
  # metrics database.
  iris = datasets.load_iris()
  test_size = 20
  
  # This is the input data for which we want to make predictions.
  # Ground truth is generally not yet known at prediction time.
  score_x = iris.data[:test_size, 2].reshape(-1, 1) # Petal length
  
  # Record the current time so we can retrieve the metrics
  # tracked for these calls.
  start_timestamp_ms=int(round(time.time() * 1000))
  
  uuids = []
  predictions = []
  for i in range(len(score_x)):
      if model_access_key is not None:
          output = cdsw.call_model(model_access_key, {"petal_length": score_x[i][0]}, api_key=user_api_key)["response"]
      else:
          output = predict({"petal_length": score_x[i][0]})
      # Record the UUID of each prediction for correlation with ground truth.
      uuids.append(output["uuid"])
      predictions.append(output["prediction"])
  
  # Record the current time.
  end_timestamp_ms=int(round(time.time() * 1000))
  
  # We can now use the read_metrics function to read the metrics we just
  # generated into the current session, by querying by time window.
  data = cdsw.read_metrics(model_deployment_crn=model_deployment_crn,
              start_timestamp_ms=start_timestamp_ms,
              end_timestamp_ms=end_timestamp_ms, dev=dev)
  data = data['metrics']
  
  # Now, ground truth is known and we want to track the true value
  # corresponding to each prediction above.
  score_y = iris.data[:test_size, 3].reshape(-1, 1) # Observed petal width
  
  # Track the true values alongside the corresponding predictions using
  # track_delayed_metrics. At the same time, calculate the mean absolute
  # prediction error.
  mean_absolute_error = 0
  n = len(score_y)
  for i in range(n):
      ground_truth = score_x[i][0]
      cdsw.track_delayed_metrics({"actual_result":ground_truth}, uuids[i], dev=dev)
  
      absolute_error = np.abs(ground_truth - predictions[i])
      mean_absolute_error += absolute_error / n
  
  # Use the track_aggregate_metrics function to record the mean absolute
  # error within the time window where we made the model calls above.
  cdsw.track_aggregate_metrics(
      {"mean_absolute_error": mean_absolute_error}, 
      start_timestamp_ms, 
      end_timestamp_ms, 
      model_deployment_crn=model_deployment_crn,
      dev=dev
  )

• Limitations

  • Scala models are not supported.

  • Spawning worker threads is not supported with models.

  • Models deployed using Cloudera Data Science Workbench are not highly-available.

  • Dynamic scaling and auto-scaling are not currently supported. To change the number of replicas in service, you will have to re-deploy the build.

The subdomain names on the Application page has some constraints, but the CDSW UI may not display a complete error message when these are violated.

Workaround: Use the characters from the set of ASCII letters, digits, and hyphens (a-z, 0-9, -) to form the subdomain name. Ensure that the subdomain name does not start or end with a hyphen.

Cloudera Bug: DSE-11883

• In the monitoring view of the Grafana the UI, the values displayed in the Used CPU Usage and the Total CPU Usage are the same when both the Node and the Pod filters are set to All.

  Workaround: Use a specific filter other than All to overcome this issue.

  Cloudera Bug: DSE-12072

• Deleting the projects through the UI might leave residual files on disk.

  Workaround: Please contact Cloudera support to remove residual files in case of disk usage issues.

  Cloudera Bug: DSE-393

• CDSW cannot launch sessions due to connection errors resulting from a segfault

  Sample error:

  transport: Error while dialing dial tcp 100.77.93.252:20051: connect: connection refused

  Workaround: Enable IPv6 on all CDSW hosts

  1. Double-check that IPv6 is currently disabled during boot time, i.e. ipv6.disable should be equal to 1.

     $ dmesg 
     [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-514.el7.x86_64 root=UUID=3e109aa3-f171-4614-ad07-c856f20f9d25 ro console=tty0 crashkernel=auto console=ttyS0,115200 ipv6.disable=1

     $ cat /proc/cmdline
     .....ipv6.disable=1

  2. Edit /etc/default/grub and delete the ipv6.disable=1 entry from GRUB_CMDLINE_LINUX. For example:

     GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/swap crashkernel=auto rd.lvm.lv=rhel/root"

  3. Run the grub2-mkconfig command to regenerate the grub.cfg file:

     grub2-mkconfig -o /boot/grub2/grub.cfg

     Alternatively, on UEFI systems, you would run the following command:

     grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

  4. Follow the above steps for both CDSW Master and Worker nodes.
  5. Stop the Cloudera Data Science Workbench service.
  6. Reboot all the Cloudera Data Science Workbench hosts to enable IPv6 support.
  7. Start the Cloudera Data Science Workbench service. Run dmesg on the CDSW hosts to ensure there are no segfault errors seen.

  Cloudera Bug: DSE-7238, DSE-7455

• Custom /etc/hosts entries on Cloudera Data Science Workbench hosts do not propagate to sessions and jobs running in containers.

  Cloudera Bug: DSE-2598

• Initialisation of Cloudera Data Science Workbench (cdsw init) will fail if localhost does not resolve to 127.0.0.1.

• Cloudera Data Science Workbench does not support DNS servers running on 127.0.0.1:53. This IP address resolves to the container localhost within Cloudera Data Science Workbench containers. As a workaround, use either a non-loopback address or a remote DNS server.
• Kubernetes throws the following error when /etc/resolv.conf lists more than three domains:

  Resolv.conf file '/etc/resolv.conf' contains search line consisting of more than 3 domains!

  Due to a limitation in the libc resolver, only two DNS servers are supported in /etc/resolv.conf. Kubernetes uses one additional entry for the cluster DNS.

• Environment variables with the dollar ($) character are not parsed correctly by CDSW. For example, if you set PASSWORD="pass$123" in the project environment variables, and then try to read it using the echo command, you see the following output: pass23

  Workaround: Use one of the following commands to print the $ sign:

  echo 24 | xxd -r -p
  or
  echo JAo= | base64 -d

  Insert the value of the environment variable by wrapping it in the command substitution using $() or ``. For example, if you want to set the environment variable to ABC$123, specify:

  ABC$(echo 24 | xxd -r -p)123
  or
  ABC`echo 24 | xxd -r -p`123

• You see the HTTP 404 error on navigating to other tabs within the CDSW web UI after updating the project name on the Project Settings page. This is because the backend API still uses the older project name.

  Workaround: After you save the new project name, manually reload the webpage before navigating to the other tabs or pages within the CDSW web UI.

  Cloudera Bug: DSE-11911

• In some cases, the application switcher (grid icon) does not show any other applications, such as Hue or Ranger.

  Cloudera Bug: DSE-865

• Scala sessions hang when running large scripts (longer than 100 lines) in the Workbench editor.

  Workaround 1:

  Execute the script in manually-selected chunks. For example, highlight the first 50 lines and select Run > Run Line(s).

  Workaround 2:

  Restructure your code by moving content into imported functions so as to bring the size down to under 100 lines.

• The R engine is unable to display multi-byte characters in plots. Examples of multi-byte characters include languages such as Korean, Japanese, and Chinese.

  Workaround: Use the showtext R package to support more fonts and characters. For example, to display Korean characters:

  install.packages('showtext')
  library(showtext)
  font_add_google("Noto Sans KR", "noto")
  showtext_auto()

  Cloudera Bug: DSE-7308

• In a scenario where 100s of users are logged in and creating processes, the nproc and nofile limits of the system may be reached. Use ulimits or other methods to increase the maximum number of processes and open files that can be created by a user on the system.

• When rebooting, Cloudera Data Science Workbench hosts can take a significant amount of time (about 30 minutes) to become ready.

• Long-running operations such as fork and clone can time out when projects are large or connections outlast the HTTP timeouts of reverse proxies.

• The Scala kernel does not support auto-complete features in the editor.

• Scala and R code can sometimes indent incorrectly in the workbench editor.

  Cloudera Bug: DSE-1218