Cloning of dynatrace-wwse/enablement-gen-ai-llm-observability main to this.main

[sergiohinojosa]

• Cloning main of dynatrace-wwse/enablement-gen-ai-llm-observability to this main. (Strategy: swap and replace)
• Packing /readme.md into docs/other LLM to have one documentation with multiple usecases.
  • '8. Other LLM 🧠':
    • 'Amazon Bedrock': bedrock.md
    • 'Multi-Mode': multi-mode.md
    • 'Ollama-Pinecone': ollama-pinecone.md
    • 'RAG': rag.md

Missing:

• Other branches not using the framework, should be migrated as well.
• Tag and Version branch
• Protect Main
• Run/Test Integration tests, add GH secrets for Organisation

[agardnerIT]

This is a huge PR that fundamentally changes everything about this demo:

1. The underlying framework and way this demo is stood up is now much more complex and relies on a framework built by the SE organisation (unknown internal support model)
2. The documentation has entirely changed and IMO is too sales-based for the original audience of this demo
3. The documentation contains links to places like Highspot which should not be public

The maintainers of the demo (@thisthat) would need to be happy that they understand and accept the added complexity of maintainance + upkeep that merging this PR brings.

[sergiohinojosa]

Hi @agardnerIT,

1. -The PR is large because it removes redundant files and unnecessary components, with the goal of reducing technical debt and complexity. Regarding the framework, new functionality such as MCP Server, testing, monitoring, and interoperability is documented here: https://dynatrace-wwse.github.io/codespaces-framework

2 and 3 .- The documentation was updated to help onboard new stakeholders into the world of LLM and OpenLLMetry, independent of Dynatrace. On the sales-related comment: the only section referencing sales resources is the “Resources” part, and I believe @thisthat added links to HS resources. I agree these should remain internal.
Additionally, the documentation now includes README files for the different branches, as it wasn’t clear that each branch represents a new use case with a distinct deployment approach. I’ll support @thisthat with anything needed to maintain and update the repository.

Still pending in the repo:

• Apply the framework to all branches for consistency
• Tag and version branches
• Protect main
• Run and test integration workflows; add GitHub secrets for the Dynatrace organisation to align with the monitoring tenant

[agardnerIT]

We have all of this in the Python framework. Plus we have a full e2e testing framework that leverages standard tools like Playwright. I'm happy to run you through this again as I know it's been a while since we covered it. IMO we should also lean on a modern stack like Python and not bash - the maintenance burden is too great.

Regardless, we need an e2e test harness before this can be merged as a broken demo is worse IMO than no demo.

If the SE org wishes to use your bash-based framework for internal usecases and demos that your team maintains, that's of course your prerogative (as you own and maintain those internal-facing demos), but it shouldn't bleed into public demos that need to be more reliable as we (DevRel) are responsible for maintaining these demos.