Known issues and limitations in Cloudera Data Engineering on CDP Private Cloud

This page lists the current known issues and limitations that you might run into while using the Cloudera Data Engineering (CDE) service.

DEX-6743: CDE CLI command execution sometimes displays End of File (EOF) error message in the end.
CDE CLI command execution sometimes displays an EOF error message in the end even though the command executes successfully. This generally happens due to error message or delay in response due to network issues or timeout error.
No workaround. But you can check for the error message in the pod logs or is it due slowness in resources over kubernetes clusters.
OPSAPS-65424: Embedded Container Service (ECS) 1.3.4 to 1.4.1 control plane upgrade looping forever in error state
Upgrading the ECS version while CDE service is enabled, can cause Control Pane upgrade looping forever in error state.
Back up CDE jobs in the CDE virtual cluster, and then delete the CDE service and CDE virtual cluster. Restore it after the upgrade. For more information about backup and restore CDE jobs, see Backing up and restoring CDE jobs.
DEX-8226: Grafana Charts of new virtual clusters will not be accessible on upgraded clusters if virtual clusters are created on existing CDE service.
If you upgrade the cluster from 1.3.4 to 1.4.x and create a new virtual clusters on the existing CDE Service, Grafana Charts will not be displayed. This is due to broken APIs.
Create a new CDE Service and a new virtual cluster on that service. Grafana Charts of the virtual cluster will be displayed.
DEX-7000: Parallel Airflow tasks triggered at exactly same time by the user throws the 401:Unauthorized error.
Error 401:Unauthorized is displayed when parallel Airflow tasks in an airflow job are triggered or launched exactly at the same time by the user.
  1. Navigate to the Cloudera Data Engineering Overview page by clicking the Data Engineering tile in the Cloudera Data Platform (CDP) management console.
  2. In the Environments column, select the environment containing the virtual cluster where you want to create the job.
  3. In the Virtual Clusters column on the right, click the View Jobs icon on the virtual cluster where you want to create the application.
  4. In the left hand menu, click Jobs.
  5. Click the Create Job button.
  6. Provide the job details:
    1. Select Airflow for the job type.
    2. Specify the job name as bashoperator-job.
    3. Save the following python script to attach it as a DAG file.
      from dateutil import parser
      from airflow import DAG
      from airflow.utils import timezone
      from airflow.operators.bash_operator import BashOperator
      ​
      default_args = {
         'depends_on_past': False,
      }
      ​
      dag = DAG(
         'bashoperator-job',
         default_args = default_args,
         start_date = parser.isoparse('2022-06-17T23:52:00.123Z').replace(tzinfo=timezone.utc),
         schedule_interval = None,
         is_paused_upon_creation = False
      )
      ​
      task1 = BashOperator(
         task_id = 'task1',
         dag = dag,
         bash_command = 'sleep 600'
      )
      ​
      task2 = BashOperator(
         task_id = 'task2',
         dag = dag,
         bash_command = 'sleep 600'
      )
      ​
      task3 = BashOperator(
         task_id = 'task3',
         dag = dag,
         bash_command = 'sleep 600'
      )
      ​
      [task1, task2] >> task3
    4. Select File, click Select a file to upload the above python, and select a file from an existing resource.
  7. Select the Python Version, and optionally select a Python Environment.
  8. Click Create and Run.
DEX-7001: When Airflow jobs are run, the privileges of the user who created the job is applied and not the user who submitted the job.
Irrespective of who submits the Airflow job, the Airflow job is run with the user privileges who created the job. This causes issues when the job submitter has lesser privileges than the job owner who has higher privileges.
Spark and Airflow jobs must be created and run by the same user.
DEX-7022: Virtual Cluster does not accept spark or airflow jobs if the tzinfo library is used as the start date.
If you use the tzinfo library for start_date, then the Virtual Cluster may not complete execution of spark or airflow jobs launched later. For example:
example_dag = DAG(
'bashoperator-parameter-job',
default_args=default_args,
start_date=parser.isoparse("2020-11-11T20:20:04.268Z").replace(tzinfo=timezone.utc),
schedule_interval='@once',
is_paused_upon_creation=False
)
Use start_date as start_date=pendulum.datetime(2017, 1, 1, tz="UTC”) instead of code like the tzinfo library. For more information about time zones, see Airflow time zone aware DAGs documention.
Changing LDAP configuration after installing CDE breaks authentication
If you change the LDAP configuration after installing CDE, as described in Configuring LDAP authentication for CDP Private Cloud, authentication no longer works.
Re-install CDE after making any necessary changes to the LDAP configuration.
Gang scheduling is not supported
Gang scheduling is not currently supported for CDE on CDP Private Cloud.
HDFS is the default filesystem for all resource mounts
For any jobs that use local filesystem paths as arguments to a Spark job, explicitly specify file:// as the scheme. For example, if your job uses a mounted resource called test-resource.txt, in the job definition, you would typically refer to it as /app/mount/test-resource.txt. In CDP Private Cloud, this should be specified as file:///app/mount/test-resource.txt.
Apache Ozone is supported only for log files
Apache Ozone is supported only for log files. It is not supported for job configurations, resources, and so on.
Scheduling jobs with URL references does not work
Scheduling a job that specifies a URL reference does not work.
Use a file reference or create a resource and specify it

Limitations

Access key-based authentication will not be enabled in upgraded clusters prior to CDP PVC 1.3.4 release.
After you upgrade to PVC 1.3.4 version from earlier versions, you must create the CDE Base service and Virtual Cluster again to use the new Access Key feature. Otherwise, the Access Key feature will not be supported in the CDE Base service created prior to the 1.3.4 upgrade.