Multiple DT staff cannot spin this up

[agardnerIT]

Raising this on behalf of a few Dynatrace employees struggling to spin this up:

A couple of us have tried, and we seem to always fail on post-create.
The best I got is a notebook and dashboard created, plus Kubernetes cluster talking to DT.
But it fails to create the workflows (or maybe I don't have the permissions to see them)

Problem 1

This is a manifestation of #22

025-01-09 05:40:02.969Z: ╷
│ Error: There cannot be 2 teams with the same identifier.

Problem 2

2025-01-09 05:40:02.969Z: ╷
│ Error: GET https://********.********.dynatrace.com/api/v2/settings/objects?repairInput=********: Constraints violated.
│ {"parameterLocation":"PAYLOAD_BODY","message":"A connection with the same name already exists. Please provide a different name.","path":"app:dynatrace.github.connector:connection/1/name"}

Problem 3

2025-01-09 05:40:03.008Z: ╷
│ Error: Unsupported attribute
│ 
│   on workflow-predict-usage.tf line 332, in resource "dynatrace_automation_workflow" "predict_resource_usage":
│  332:         connection = jsondecode(data.http.get_edge_connect.response_body).items[0].objectId,
2025-01-09 05:40:03.009Z: │     ├────────────────
│     │ data.http.get_edge_connect.response_body is "{\"error\":{\"code\":404,\"message\":\"Configuration schema app:dynatrace.kubernetes.connector:connection does not exist.\"}}"
│ 
│ This object does not have an attribute named "items".

[grabnerandi]

To add some additional information as I was able to successfully run this codespace but initially also run into the issue
1: you need to make sure your tenant fulfills all prerequsists, e.g: Having access to the Davis CoPilot API
2: you can ONLY run this demo ONCE on a Dynatrace tenant as it will configure certain settings, e.g: teams that would otherwise be duplicated
3: When shutting down the codelab make sure to call the destroy.sh as explained here https://dynatrace.github.io/obslab-predictive-kubernetes-scaling/cleanup/ - this will cleanup any configuration that would otherwise cause issues when you run the codelab a second time

Another issue I ran into was that the GitHub Search API seems to have issues with finding files based on file content. The same search that works perfectly through the GitHub Web UI doesnt return any results in the Search API. I think thats a current issue or limitation of GitHub. For this particular codelab however the "workaround" is to update the Dynatrace Workflow and - instead of waiting for the GitHub API Search Result - simply return the file name we are looking for - which is the deployment.yaml file.

[163a]

Thanks Adam and Andi,
I still get the problem on destroy.sh:
data.http.get_edge_connect: Read complete after 0s [id=https://abc12345.live.dynatrace.com/api/v2/settings/objects?schemaIds=app:dynatrace.kubernetes.connector:connection&filter=value.name='cautious-robot-49934934'] ╷ │ Error: Unsupported attribute │ │ on workflow-predict-usage.tf line 332, in resource "dynatrace_automation_workflow" "predict_resource_usage": │ 332: connection = jsondecode(data.http.get_edge_connect.response_body).items[0].objectId, │ ├──────────────── │ │ data.http.get_edge_connect.response_body is "{\"error\":{\"code\":404,\"message\":\"Configuration schema app:dynatrace.kubernetes.connector:connection does not exist.\"}}" │ │ This object does not have an attribute named "items". ╵

[grabnerandi]

HI @163a - I just walked through the whole scenario and noticed the following
1: you need to make sure you have no left-overs of a previous demo. Things that I found leftover if the destroy.sh didnt run well is the Ownership Team as well as the GitHub connection. I had to manually delete those as at one attempt the deletion wasnt clean. So - please make sure that none of those config eleements are left-over from a previous run
2: Make sure you have all the pre-requisite apps installed, e.g: GitHub Automation as well as Kubernetes Automation. Those have to be installed and I think could also explain the issue you explain in your most recent comment
3: Also be aware that another pre-requisite is the Davis Conversational API - make sure you also have that enabled on your tenant

Now - there is one other issue with the Workflow that opens the Pull Reuqest. It has acutally nothing to do with the Workflow but with the fact that GitHub currently doesnt seem to index those repositories. Therefore the GitHub API Search that this workflow does will always fail. To workaround this I simply commented the API Call to GitHub and hard-code the return of the apps/horizontal-scaling/hpa.yml when the uuid is c4e9324f-312f-4a1c-9d32-c8288d73626b or apps/vertical-scaling/deployment.yaml when uuid is bc1299a-58ae-4c19-9533-b19c1b8ca57f

Let me know if this makes sense