What is this action supposed to do? Is this a typo?

[smktpd]

https://github.com/temporalio/helm-charts/blob/main/charts/temporal/templates/server-job.yaml#L73-L74

curl -X PUT --fail --user "$ES_USER:$ES_PWD" $ES_SCHEME://$ES_HOST:$ES_PORT/_template/temporal_visibility_v1_template -H "Content-Type: application/json" --data-binary "@schema/elasticsearch/visibility/index_template_$ES_VERSION.json" 2>&1 &&
\
curl -X PUT --fail --user "$ES_USER:$ES_PWD" $ES_SCHEME://$ES_HOST:$ES_PORT/$ES_VISIBILITY_INDEX 2>&1

The second PUT is without any payload, is this correct? I get status 400 Bad request and I think it's a correct response to such a request.
I used to init/migrate_up dependent DBMS and ES manually, so:

curl -sSL 'https://raw.githubusercontent.com/temporalio/temporal/main/schema/elasticsearch/visibility/cluster_settings_v7.json' |
        curl --user "${temporal_es_user}":"${temporal_es_pass}" -X PUT -H "Content-Type: application/json" \
                --data-binary @- --write-out "\n" "${temporal_es_addr}/_cluster/settings" && \
curl -sSL 'https://raw.githubusercontent.com/temporalio/temporal/main/schema/elasticsearch/visibility/versioned/v7/index_template_v7.json' |
        curl --user "${temporal_es_user}":"${temporal_es_pass}" -X PUT -H "Content-Type: application/json" \
                --data-binary @- --write-out "\n" "${temporal_es_addr}/_template/temporal_visibility_v1_template"

So:

• my 2nd curl query seems to do the same what your 1st one does;
• your script is missing my 1st query - I don't really know if it's mandatory/important, but I actually took it from your code somewhere in this repo (or from an image building repo, can't remember) - shouldn't this be added to the chain of actions there?
• your script does weird PUT without payload at the end, I think it is a typo and you probably wanted GET instead to get a 200 status response with the config/description of the created index.

[smktpd]

@robholland could you confirm its a typo (and thus a bug), rather than intentional?

[robholland]

It's not a typo, this is used to create an index using the template that the 2nd line added. We are missing the cluster settings file in the helm charts. It should (roughly) match https://github.com/temporalio/docker-builds/blob/main/docker/auto-setup.sh#L347 and it looks like it's lagged from that. I'll get it updated. I'm not sure why you are seeing a 400 error though.

[smktpd]

All the necessary files exist in the temporal-admintools image, so it shouldn't be an issue for kind: Job, the issue is that the set of curl commands it executes doesn't seem to match the set you linked inside the auto-setup.sh

[smktpd]

@robholland I stumbled upon this 400 again (it's now probably worth converting this discussion into an issue, what do yo think?):

{
  "error": {
    "root_cause": [
      {
        "type": "resource_already_exists_exception",
        "reason": "index [temporal_visibility_v1/akwL5UAITXORfqUDoIdWUA] already exists",
        "index": "temporal_visibility_v1",
        "index_uuid": "akwL5UAITXORfqUDoIdWUA"
      }
    ],
    "type": "resource_already_exists_exception",
    "reason": "index [temporal_visibility_v1/akwL5UAITXORfqUDoIdWUA] already exists",
    "index": "temporal_visibility_v1",
    "index_uuid": "akwL5UAITXORfqUDoIdWUA"
  },
  "status": 400
}

So this set of curl commands is not idempotent and may break like this upon upgrade of temporal, when the index already exists.