Help Center> Cloud Container Instance (CCI)> API Reference> Appendix> Constraints on OBS Bucket Mounting
View PDF

Constraints on OBS Bucket Mounting

CCI uses an additional container (sidecar container) of a pod to mount an OBS path and then shares the path with the main container of the pod, as shown in Figure 1.

Figure 1 Sidecar container

The constraints on OBS mounting are as follows:

  • When creating a pod, add the following field to annotations: obssidecar-injector-webhook/inject: 'true' 
    {
    "apiVersion": "batch/v1",
    "kind": "Job",
    "metadata": {
        "annotations": {
            "description": ""
        },
        "enable": true,
        "name": "obs-casoffinder",
        "namespace": "cci-namespace-tibgpu",
        "labels": {}
    },
    "spec": {
        "template": {
            "metadata": {
                "enable": true,
                "name": "obs-casoffinder",
                "annotations": {
                    "obssidecar-injector-webhook/inject": "true",
                    "obssidecar-injector-webhook/cpu": "500m",
                    "obssidecar-injector-webhook/memory": "2048Mi"
                }
            },
            "spec": {
                "containers": [
                    {
                        "image": "swr.cn-north-1.myhuaweicloud.com/aeocdc/opencl1:v1",
                        "name": "casoffinder-obs",
                        "terminationMessagePolicy": "File",
                        "resources": {
                            "limits": {
                                "cpu": "4",
                                "memory": "32Gi",
                                "nvidia.com/gpu-tesla-p4-8GB": "1"
                            },
                            "requests": {
                                "cpu": "4",
                                "memory": "32Gi",
                                "nvidia.com/gpu-tesla-p4-8GB": "1"
                            }
                        },
                        "command": [
                            "/bin/sh",
                            "-c",
                            "/tmp/obs0/gBIG/cas-offinder /tmp/obs0/gBIG/off_targetInput.txt G /tmp/obs0/gBIG/off_targetOutput.txt  && echo >/obssidecar/terminate/0"
                        ],
                        "lifecycle": {},
                        "volumeMounts": [
                            {
                                "name": "cci-obs-import-jzt9g50x-tunn",
                                "mountPath": "/tmp/obs0"
                            }
                        ]
                    }
                ],
                "imagePullSecrets": [
                    {
                        "name": "imagepull-secret"
                    }
                ],
                "restartPolicy": "Never",
                "volumes": [
                    {
                        "persistentVolumeClaim": {
                            "claimName": "cci-obs-import-jzt9g50x-tunn"
                        },
                        "name": "cci-obs-import-jzt9g50x-tunn"
                    }
                ]
            }
        },
        "activeDeadlineSeconds": 200
    }
}
  • Constraints on startup commands:
    • The bash mode is recommended when the YAML file is used to configure container startup commands.

      trap '[ -d /obssidecar/terminate ] && echo > /obssidecar/terminate/0' EXIT && sleep 10

      Example: 
      {
    "command": [
        "/bin/sh",
        "-c",
        "trap '[ -d /obssidecar/terminate ] && echo > /obssidecar/terminate/0' EXIT && sleep 10"
    ]
}
    • You do not need to configure startup commands if user containers have been embedded with startup commands or containers will not exit.

      For containers that have been embedded with startup commands, make sure that the containers write any file to /obssidecar/terminate/ when they exit. In this way, sidecar containers can detect the exit of the user containers.

Parent topic: Appendix