OECC demo

[edselg]

Sample scripts to create an OpenEdge Command Center configuration.

[DustinGrau-PSC]

I'm curious to step through this but I'll need a proper Linux VM first. In the meantime I have some comments around some of the organization and purpose of some items added.

[DustinGrau-PSC]

Reorganization is much appreciated, as is the updated purpose/comments throughout. Got a few more comments as I'm getting deeper into the scripts and slowly understanding what everything does.

[DustinGrau-PSC]

How should a user install Docker for Ubuntu? Could we add a link to something like this page or embed some instructions? https://docs.docker.com/engine/install/ubuntu/

Asking as my Ubuntu installation came with Docker 20.0.5 but following those instructions got me up to version 27.0.2 so it may be worth stating that as a reference for those people unfamiliar with Docker.

[edselg]

Calling ./scripts/setup.sh would call ../common/scripts/install_docker.sh which performs the installation of Docker on Ubuntu.

[DustinGrau-PSC]

I was honestly not aware of that, and apparently did not look that closely at the setup.sh script to realize.

This is why I've been incredibly pedantic during the code review and this is exactly what has stopped me from proceeding further than I would have liked. There are a LOT of assumptions made about the skillset of the user, familiarity with the technology, and perhaps some details missed because you are writing as the subject matter expert. It's easy to miss things or take for granted what you already know. I would ask that you take another look at the opening of the main README file, specifically the Requirements and Components sections to add notes about where each should come from.

For example, for the OpenEdge media, state those should come from the ESD site, and where they might be found. For the components such as Docker, Grafana, etc. state that those are installed by the scripts if that's the case--otherwise, explain how to manually install them (apt-get, etc.) so users know they need to have them installed before proceeding.

[edselg]

The intention of the demo scripts is to provide something that reduces the complexity of the installation process of OpenEdge Command Center and also gives the user the option to try the OpenTelemetry metrics support.
The demo scripts encapsulate the instructions. They are an updated version of the scripts used for the following blog post:

• https://www.progress.com/blogs/using-opentelemetry-metrics-support-openedge-azure

I am hoping to write a new version of the blog post.

Please try running ./scripts/setup.sh.

Thanks.

[DustinGrau-PSC]

As someone who has had little exposure to any of this, I'm now curious how much is OECC and how much is for OTel? Would this have been better to demonstrate as 2 separate examples? OECC should just be OECC, OTel just OTel. By mixing components it's difficult to know which is required or optional for their respective technology.

We already have a separate Kafka folder that demonstrates just that technology--why mix these concepts under OECC?

[edselg]

If feel that we can go either way on this.

The idea of having both together was because, at the time that the initial scripts were written and perhaps still today, OpenTelemetry is one of the most important features when using OpenEdge Command Center.
Related link: https://www.progress.com/openedge/features/command-center

It might be likely that users exploring OpenEdge Command Center (server) would also be interested on taking a look at the OpenTelemetry support.

A demo for OpenTelemetry only needs the configuration of OpenEdge Command Center agent.
Perhaps, we can have a simplified version of the demo scripts that only needs OpenEdge Command Center agent.
The interface to setup the demo would still be the same:

cd <demo-directory>
./scripts/setup.sh

Thanks.

[DustinGrau-PSC]

If I were a new looking at this folder as just "OECC" I would assume that these are all required and normal components. Having to install several extra tools to get OECC running without differentiation makes this feel more complicated than it should be.

You already have a "common" scripts folder, so why not make these subtopics which isolates learning?

• Examples/OECC
  • OECC (Standalone)
  • OECC + OpenTelemetry

[edselg]

Where are you expecting these subtopics?
Are thinking on the being part of OpenEdge-Samples/examples/OECC?
Or are you think on separate demos?

The current README.md file has a "Creating a Dashboard in Grafana" as a separate section on the demo.

I can add an optional section to the README.md on "Using OpenTelemetry Support in OpenEdge" and leave the core of the README.md to be OpenEdge Command Center.

Please confirm.

Thanks.

[DustinGrau-PSC]

Where did this work originate? Do we have a ticket that explains the purpose of the work, acceptance criteria, etc? Or is this all just off-the-cuff? We should really be tracking the work and should have discussed what goes into these examples as a matter of agreeing on the content. The more I'm diving into this the more confused I am over why I would need Docker and all these other tools just to install something that already has installer files. The OECC itself would be on a central server/location while the agent would be installed on multiple client machines, so it's hard to visualize using this in a distributed manner.

If the need for Docker is so the instance can be easily encapsulated, then there should be a Docker container for the OECC (server) component while a separate container with a PASOE instance and the agent would be installed together. That way it could demonstrate how to set up each side of the solution. This could all be a single document that is the OECC example itself--nothing more. The addition of OTel, Grafana, etc. just seem extraneous and should be it's own topic for after you've successfully set up OECC to monitor a PAS instance. That way the user could deploy the things needed to each side--either the server side of the components or the agent-monitored instances.