Hello community. I have got a question about doing...
# ask-community
a
Hello community. I have got a question about doing a helm release for
2.19.3 (2024.5.30190018)
, specifically regarding the baseJobTemplate. I understand that I have to pass a JSON string to that, however, everytime, the helm install tries to create a default base job configmap and tries to attach it to my helm release. Any idea what is going on?
Copy code
## Deployment Configuration
worker:
  # -- unique cluster identifier, if none is provided this value will be infered at time of helm install
  clusterUid: ""

  image:
    # -- worker image repository
    repository: prefecthq/prefect
    ## prefect tag is pinned to the latest available image tag at packaging time.  Update the value here to
    ## override pinned tag
    # -- prefect image tag (immutable tags are recommended)
    prefectTag: 2.19.3-python3.11-kubernetes
    # -- worker image pull policy
    pullPolicy: IfNotPresent
    ## Optionally specify an array of imagePullSecrets.
    ## Secrets must be manually created in the namespace.
    ## ref: <https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/>
    ## e.g:
    ## pullSecrets:
    ##   - myRegistryKeySecretName
    # -- worker image pull secrets
    pullSecrets: []
    # -- enable worker image debug mode
    debug: false

  ## general configuration of the worker
  config:
    # -- the work pool that your started worker will poll.
    workPool: ""
    # -- one or more work queue names for the worker to pull from. if not provided, the worker will pull from all work queues in the work pool
    workQueues: []
    # -- how often the worker will query for runs
    queryInterval: 5
    # -- when querying for runs, how many seconds in the future can they be scheduled
    prefetchSeconds: 10
    # -- connect using HTTP/2 if the server supports it (experimental)
    http2: true
    ## You can set the worker type here.
    ## The default image includes only the type "kubernetes".
    ## Custom workers must be properly registered with the prefect cli.
    ## See the guide here: <https://docs.prefect.io/2.11.3/guides/deployment/developing-a-new-worker-type/>
    # -- specify the worker type
    type: kubernetes
    ## one of 'always', 'if-not-present', 'never', 'prompt'
    # --  install policy to use workers from Prefect integration packages.
    installPolicy: prompt
    # -- the name to give to the started worker. If not provided, a unique name will be generated.
    name: null
    # -- maximum number of flow runs to start simultaneously (default: unlimited)
    limit: null
    # -- JSON formatted base job template. If unspecified, Prefect will use the default base job template for the given worker type. If the work pool already exists, this will be ignored.
    baseJobTemplate: ${BASE_JOB_TEMPLATE}
j
Hey Alan -- can you share a bit more about what you are seeing?
I don't see in your values where your passing the basejob template
Here are some docs describing how to do this, let me know if this doesn't help
a
I am setting the
baseJobTemplate: ${BASE_JOB TEMPLATE}
, which I am using in a helm release in terraform:
Copy code
resource "helm_release" "prefect_worker_gpu" {
  for_each = { for np in var.karpenter_node_pools_gpu : np.node_pool_name => np }

  name       = "prefect-worker-${each.value.workpool_name}"
  namespace  = "${var.environment}-prefect"
  chart      = "prefect-worker"
  repository = "<https://prefecthq.github.io/prefect-helm>"
  version    = "${var.prefect_chart_version}"


  values = [templatefile("${path.module}/values/values-worker.yaml", {
    UI_URL = "<https://prefect>-${var.product_name}-${var.environment}.**.com"
    EXISTING_SECRET = "${kubernetes_secret.db_secret.metadata[0].name}"
    CERTIFICATE_ARN = "${data.aws_acm_certificate.env.arn}"
    SECURITY_GROUP = "${var.prefect_security_group_id}"
    API_URL = "<http://prefect-server>.${var.environment}-prefect.svc.cluster.local:4200/api"
    WORK_POOL_NAME = "${each.value.workpool_name}"
    FULL_NAME_OVERRIDE = "prefect-worker-${each.value.workpool_name}"
    IS_INITIAL = false
    BASE_JOB_TEMPLATE = jsonencode(templatefile("${path.module}/values/baseJobTemplateGPU.json.tpl", {
                             prefect_hq_version  = "${var.prefect_hq_version}"
                             environment    = "${var.environment}"
                             node_pool_name = "${each.value.node_pool_name}"
                             num_gpus = "${each.value.num_gpus}"
                           }))
  })]


  depends_on = [ helm_release.prefect_server, kubernetes_config_map.base_job_template_gpu, kubernetes_config_map.base_job_template_cpu, kubernetes_namespace.prefect, kubernetes_secret.prefect_api_key ]
}
I have another helm release for cpu workpools, much the same way:
Copy code
resource "helm_release" "prefect_worker_cpu" {
  for_each = { for np in var.karpenter_node_pools_cpu : np.node_pool_name => np }

  name       = "prefect-worker-${each.value.workpool_name}"
  namespace  = "${var.environment}-prefect"
  chart      = "prefect-worker"
  repository = "<https://prefecthq.github.io/prefect-helm>"
  version    = "${var.prefect_chart_version}"


  values = [templatefile("${path.module}/values/values-worker.yaml", {
    UI_URL = "<https://prefect>-${var.product_name}-${var.environment}.*.com"
    EXISTING_SECRET = "${kubernetes_secret.db_secret.metadata[0].name}"
    CERTIFICATE_ARN = "${data.aws_acm_certificate.env.arn}"
    SECURITY_GROUP = "${var.prefect_security_group_id}"
    API_URL = "<http://prefect-server>.${var.environment}-prefect.svc.cluster.local:4200/api"
    WORK_POOL_NAME = "${each.value.workpool_name}"
    FULL_NAME_OVERRIDE = "prefect-worker-${each.value.workpool_name}"
    IS_INITIAL = false
    BASE_JOB_TEMPLATE = jsonencode(templatefile("${path.module}/values/baseJobTemplateCPU.json.tpl", {
                          prefect_hq_version  = "${var.prefect_hq_version}"
                          environment    = "${var.environment}"
                          node_pool_name = "${each.value.node_pool_name}"
                        }))
  })]


  depends_on = [ helm_release.prefect_server, kubernetes_config_map.base_job_template_gpu, kubernetes_config_map.base_job_template_cpu, kubernetes_namespace.prefect, kubernetes_secret.prefect_api_key ]
}
When I run terraform, I get a very peculiar error:
Copy code
Error: context deadline exceeded
  with module.prefect.helm_release.prefect_worker_gpu["karpenter-nodepool-gpu-2x"],
  on tfmodules/prefect/workers.tf line 1, in resource "helm_release" "prefect_worker_gpu":
   1: resource "helm_release" "prefect_worker_gpu" {
Error: Unable to continue with install: ConfigMap "prefect-worker-base-job-template" in namespace "dev-prefect" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "<http://meta.helm.sh/release-name|meta.helm.sh/release-name>" must equal "prefect-worker-work-cpu": current value is "prefect-worker-work-gpu"
  with module.prefect.helm_release.prefect_worker_cpu["karpenter-nodepool-cpu-4x"],
  on tfmodules/prefect/workers.tf line 27, in resource "helm_release" "prefect_worker_cpu":
  27: resource "helm_release" "prefect_worker_cpu" {
For some reason, it is creating its own configmap with the default base job template and trying to associate it to the helm release?!
My question is, why is it creating a ConfigMap "prefect-worker-base-job-template" when I provided a JSON string for the baseJobTemplate? Also, why is it trying to associate that configmap with anyone of of my helm releases?!
j
Ah i see - the helm chart creates a config map to store the base job template you provide & load it to the worker pod
it looks like there is a name conflict of the config maps... are you setting a unique value for the
Values.worker.config.baseJobTemplate.name
I think if you set a unique value for the config map name, that should solve your error!
a
does that chart version allow baseJobTemplate.name?
baseJobTemplate accepts a json string
image.png
image.png
j
ah i see - you are operating on an older version - can you try this version?
a
unfortunately I cannot as we have a current requirement to stay on prefect 2.19.3! Anyways, I think if i use a different namespace for each one, it will have to work for now!!
j
you can override the prefect version to use by specifyying
worker.image.prefectTag
a
is that safe to do?
j
yep, here is the list of images using 2.19.3
a
wow that would be great actually
j
🙂
a
YOU ARE AWESOME
that worked and simplified everything!!
j
anytime!!!